ci(win): produce separate VS2019/VS2022/VS2026 developer distributives#6263
Merged
Conversation
Previously a single Windows developer archive (MeshLibDist_<ver>.zip) was
built only from the VS2019 CMake build. Build three archives instead, one per
Visual Studio toolchain, under the same circumstances (scheduled/full-ci/
build-release-windows runs and the by-tag Windows release workflow):
- MeshLibDistVS19_<ver>.zip (was MeshLibDist_<ver>.zip, VS2019)
- MeshLibDistVS22_<ver>.zip (VS2022)
- MeshLibDistVS26_<ver>.zip (VS2026)
- build-test-windows.yml: upload a developer archive from every VS CMake build
(not just VS2019); tag the MREDist/WindowsArchive names with VS19/VS22/VS26
so they no longer collide. The compiler-independent C2 headers archive is
still uploaded once (from VS2019) to avoid racing same-named uploads.
- update-win-version.yml: one matrix leg per toolchain, each repackaging its
archives into MeshLibDistVS{19,22,26}.zip with the matching vcpkg baseline
and triplet; new vs22_vcpkg_version input. The iterator-debug archive is
unchanged.
- build-test-distribute.yml / distro-release.yml: pass vs22_vcpkg_version and
rename per-VS archives to MeshLibDistVSxx_<ver>.zip (iterator-debug keeps its
historical MeshLibDist_<ver>-IteratorDebug.zip name).
- windows-standard/finalize-release matrices: add the VS2022/VS2026 CMake
Debug+Release legs so those paths also build all three archives.
- test-distribution.yml: smoke-test all three archives.
- release_table.txt: link all three Windows archives.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The VS2026 developer archive now comes from the msvc-2026 MSBuild build (which also produces the C#/.NET components and uses the v143 CUDA toolset), while VS2019 and VS2022 keep shipping their CMake builds. - build-test-windows.yml: upload the distributive from the msvc-2026 MSBuild build and from the msvc-2019/msvc-2022 CMake builds. - windows-standard/finalize-release matrices: provide the VS2026 Debug+Release MSBuild legs (the full config already had them); drop the VS2026 CMake legs that were only added for the archive. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With the VS2026 distributive now built from MSBuild, the msvc-2026 CMake Debug leg in the standard (build-release-windows) config no longer produces an archive and is not consumed by anything; the VS2026 Debug tests still run via the new MSBuild Debug leg. Drop it so every standard-config leg maps to a release archive. CMake VS2026 build coverage remains in the full config used by full-ci / scheduled runs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Grantim
approved these changes
Jun 15, 2026
The VS2026 distributive is built from the MSBuild job, whose C# test run (MRDotNet2Test) leaves a debug-symbol cache under x64/<config>/sym (coreclr/ntdll/kernelbase PDBs, indexed by GUID). copy_lib() copies x64/ wholesale and keeps every .pdb, so ~20 MB of Windows/CLR system symbols were shipping inside MeshLibDistVS26.zip. Remove the install/lib/*/sym caches before packaging. No-op for the VS2019/VS2022 (CMake) archives, which have no such cache. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The Windows release currently ships a single developer archive,
MeshLibDist_<ver>.zip, built only from the VS2019 CMake build. This PRproduces three archives instead — one per Visual Studio toolchain — built under
the same circumstances (scheduled /
full-ci/build-release-windowsruns andthe by-tag "Windows Release by Tag" workflow):
MeshLibDistVS19_<ver>.zip— what was previouslyMeshLibDist_<ver>.zip(VS2019)MeshLibDistVS22_<ver>.zip— VS2022MeshLibDistVS26_<ver>.zip— VS2026Changes
VS2019/VS2022 from their CMake builds, VS2026 from its MSBuild build (which
also produces the C#/.NET components). A new
VS_TAGenv (VS19/VS22/VS26)is woven into the
MREDist_*/WindowsArchive_*names so the per-toolchainarchives no longer collide. The compiler-independent C2 headers archive is
still uploaded once (from VS2019) to avoid racing same-named uploads.
archives into
MeshLibDistVS{19,22,26}.zipusing the matching vcpkg baselineand triplet. Adds a
vs22_vcpkg_versioninput. The iterator-debug leg isunchanged.
vs22_vcpkg_versionand rename the per-VS archives to
MeshLibDistVSxx_<ver>.zip. Theiterator-debug archive keeps its historical
MeshLibDist_<ver>-IteratorDebug.zipname.CMake and VS2026 MSBuild Debug+Release legs so those paths also build all three
archives (the full config already had them).
release notes.
Validation
Labeled
full-cito exercise the full Windows config (all three toolchains,Debug+Release) end-to-end, with the non-Windows platforms disabled since they are
untouched. The resulting
-pr-testdraft release should containMeshLibDistVS19/VS22/VS26_<ver>.zipplus the unchanged iterator-debug archive.Notes
MeshLibDist_<ver>.zipname.pushto master (minimal config) the broadened upload gate now alsouploads one extra binary archive that is discarded unconsumed (same pattern as
the pre-existing VS2019 push uploads); the per-VS distributives themselves are
only repackaged on release runs. Happy to gate the upload on
build-release-wininstead if preferred.