Jens-G opened a new pull request, #3917:
URL: https://github.com/apache/thrift/pull/3917

   Doc-only. Noticed while adding the Windows compiler CI job; filed then 
rather than folded in.
   
   The MSVC container directory was renamed `build/docker/msvc2017` → 
`build/docker/msvc` and the paths naming it were not updated: 
`doc/ReleaseManagement.md` had a **broken relative link**, and the README in 
that directory told the reader to run commands against paths that do not exist 
— six times.
   
   While in there, three other things had gone stale.
   
   ## The pull instruction could not have worked
   
   It said to `docker pull thrift/thrift-build:msvc2017`. That Docker Hub 
repository carries the **Linux images only** — I checked the tag list:
   
   ```
   ubuntu-bionic, ubuntu-focal, ubuntu-xenial, ubuntu-artful, ubuntu-trusty,
   debian-jessie, debian-stretch, ubuntu, debian, centos
   ```
   
   No `msvc2017`, no Windows tag at all. `msvc.yml` builds the image itself and 
caches it in **GHCR** under a tag derived from the hash of the Dockerfile *and* 
the scripts it copies, so a run only rebuilds when one of those changes. That 
is what the README now describes.
   
   It also now says the build context is `build\`, not the Dockerfile's own 
directory — necessary because the image copies from `build\appveyor\`, easy to 
get wrong, and previously stated nowhere.
   
   ## It still claimed a statically linked compiler
   
   > you will see it only depends on KERNEL32.DLL which means the runtime is 
statically linked
   
   That stopped being true when the project moved away from a statically linked 
compiler. [#3901](https://github.com/apache/thrift/pull/3901) (THRIFT-6320) 
corrected exactly this claim in `ReleaseManagement.md` and left this copy 
behind.
   
   It now states what is actually expected — the Visual C++ redistributable, 
and nothing else beyond Windows system DLLs — and points at 
`check-compiler-imports.ps1` and the `compiler-windows` job, which assert it on 
every push.
   
   ## Size and nano
   
   > The build image is very large (just under 30GB) … Once Microsoft supports 
build tools in nano, it should get better.
   
   THRIFT-5952 and THRIFT-6237 have both worked on the image size since, so 
that number is not one to quote. It now just says the image is large. The nano 
remark went with it; the base image is 
`mcr.microsoft.com/dotnet/sdk:10.0-windowsservercore-ltsc2025`.
   
   ## Checked
   
   No `msvc2017` remains anywhere in the tree, and every relative link in the 
rewritten README resolves **from the README's own directory** (not just from 
the repo root, which is the easy way to get this wrong):
   
   ```
   OK  ../../../.github/workflows/msvc.yml
   OK  ../../../.github/workflows/cmake.yml
   OK  ../../../doc/ReleaseManagement.md
   OK  ../build/docker/msvc/README.md        (from doc/)
   ```
   
   JIRA: [THRIFT-6315](https://issues.apache.org/jira/browse/THRIFT-6315)
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to