ci: pin Windows jobs to the windows-2022 runner - #2
Merged
Conversation
The windows-latest image no longer ships Visual Studio 2022; it now
provides Visual Studio 18 (VSINSTALLDIR .../Visual Studio/18/Enterprise,
VisualStudioVersion 18.0). Every Windows job in this workflow configures
CMake with -G "Visual Studio 17 2022", so they all fail at configure time:
CMake Error at CMakeLists.txt:2 (project):
Generator
Visual Studio 17 2022
could not find any instance of Visual Studio.
Nothing in the repository changed -- this workflow is byte-identical to
the last commit whose CI was fully green -- so pin the Windows matrix
entries to windows-2022, which still provides the toolchain the generator
asks for. This restores exactly the configuration that was last green.
Only ci.yml hardcodes the generator; vcpkg.yml and conan.yml let CMake
pick one and their Windows jobs still pass on windows-latest, so they are
left alone.
Follow-up: adopt Visual Studio 18 on windows-latest so this does not need
revisiting when windows-2022 is retired. That is a separate change since
it builds against a toolchain these projects have not been tested with.
openssl/4.0.1 reached conancenter, and the unbounded openssl/[>=3.0] range started resolving to it. minizip-ng/4.2.1 requires openssl/[>=1.1 <4], so the graph no longer resolves: ERROR: Version conflict: Conflict between openssl/[>=1.1 <4] and openssl/4.0.1 in the graph. Conflict originates from minizip-ng/4.2.1 Cap the range at <4 so it agrees with minizip-ng and keeps resolving to OpenSSL 3.x, which is what this package is built and tested against. Same class of breakage as the Windows runner change in this PR: an unpinned upstream moved, not a change in this repository.
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
The Windows CI jobs (
Windows MSVC Module Debug/Release) fail at the CMake configure step:Nothing in this repository changed. The runner image moved underneath us:
windows-latestno longer ships Visual Studio 2022. The job logs showso the
-G "Visual Studio 17 2022"generator no longer resolves. (Confirmed against NekoNetwork, where the identical workflow is byte-identical to its last all-green commit and now fails the same way.)Change
Pin the Windows matrix entries to
windows-2022, which still provides the toolchain the generator asks for. Same compiler, same matrix, no toolchain change:- { name: "Windows MSVC Module Debug", - os: windows-latest, + os: windows-2022,Scope
Only
ci.ymlhardcodes a generator.vcpkg.ymlandconan.ymllet CMake pick one and their Windows jobs still pass onwindows-latest, so they are left untouched.The same breakage affects all seven Neko repos; a matching PR is open on each.
Follow-up
This pins to an image GitHub will eventually retire. Adopting Visual Studio 18 on
windows-latestis the durable fix, but it builds against a toolchain these projects have not been tested with — the C++20 module jobs here in particular — so it belongs in its own change.Note
Intentionally separate from #1, which addresses the vcpkg maintainer's upstream feedback. The two are unrelated.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WMgcdYggBJ6aMCuNXYbRZT
Generated by Claude Code