ci(windows): fix windows-2025 generator and windows-11-arm SHLWAPI legs - #2471
Merged
Merged
Conversation
windows-2025 ships Visual Studio 2026 only, so the hardcoded "Visual Studio 17 2022" generator finds no VS instance; select the generator per image (VS 18 2026 on windows-2025). windows-11-arm fails at generate time because GetUMWindowsSDKLibraryDir returns an empty directory on ARM64 images, leaving SHLWAPI_LIBRARY NOTFOUND; link shlwapi by name and let the linker resolve it from the per-architecture SDK library paths. Both legs stay continue-on-error until verified green; a follow-up commit in this PR will make them blocking (see #2461).
Per the runner-images Windows2025 README, plain windows-2025 and windows-11-arm ship VS2022; only the new *-vs2026 labels ship VS2026. Select the generator by label suffix instead of assuming windows-2025 lacks VS2022, and add windows-2025-vs2026 / windows-11-vs2026-arm legs (default toolset; the v143 availability on VS2026 images is unverified). Empty toolsets skip -T entirely. All four non-2022 legs stay continue-on-error until verified.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2471 +/- ##
==========================================
- Coverage 85.40% 85.39% -0.01%
==========================================
Files 126 126
Lines 22964 22958 -6
==========================================
- Hits 19612 19605 -7
- Misses 3352 3353 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The live windows-2025 image exposes no VS2022 instance even though the runner-images README lists VS Enterprise 2022, so label-based generator selection still failed there. Ask vswhere what is actually installed and map 17->VS2022 / 18->VS2026 generators; keep -T only for VS2022 since the VS2026 images may not ship the v143 toolset.
Direct bash invocation of the Program Files (x86) vswhere is known not to work on these images; the toolchain step already uses the Chocolatey shim through cmd. Strip the CRLF cmd appends.
An extra ']' after the [ -n ... ] test would abort every configure step under set -e before cmake ran.
All four (windows-2025, windows-11-arm, windows-2025-vs2026, windows-11-vs2026-arm) are verified green with the vswhere-driven generator detection. Closes #2461.
6 tasks
Contributor
Author
|
@ni4 this is the windows CI fix that unblocks the windows-11-arm leg across all PRs (including #2472): #2471 CI/workflow-only change (no runtime code), so just needs your solo approval. It:
Closes #2461. Once this merges, #2472's windows-11-arm goes green and both can land. |
Contributor
Author
|
Thanks @ni4 ! The only failures are codecov 0.01% and the two fuzzing jobs that are blocked by google/oss-fuzz#15882, so everything is passing here. Merging. |
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.
Summary
Makes the two non-blocking windows preview legs actually work (#2461), so they can start gating like the rest of the matrix.
windows-2025 — generator selection
cmake -G "Visual Studio 17 2022"fails with could not find any instance of Visual Studio: the image ships VS 2026 only (generator version 18). A new step selects the generator per image (Visual Studio 18 2026on windows-2025, unchanged elsewhere) and both configure steps use it.windows-11-arm — SHLWAPI discovery
Configure fails with
SHLWAPI_LIBRARY ... NOTFOUNDbecauseGetUMWindowsSDKLibraryDirreturns an empty directory on the ARM64 images (-- Using Windows SDK library directory:). The WindowsSDK-module probing is dropped entirely;shlwapiis now linked by name and resolved by the linker from the per-architecture Windows SDK library paths, which works on every architecture.Sequencing
The legs remain
continue-on-errorwhile this PR verifies them green; the final commit here removes the exemption so they become blocking.Closes #2461 (once the exemption is removed).
Test plan
continue-on-erroronce both are green