ci: run V8 source builds on Windows 2025#31356
Conversation
2a2c345 to
251e09b
Compare
251e09b to
088856e
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 251e09b310
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - runner: windows-2025 | ||
| target: x86_64-pc-windows-msvc | ||
| - runner: windows-2022 | ||
| - runner: windows-2025 | ||
| target: aarch64-pc-windows-msvc |
There was a problem hiding this comment.
Keep the source build on a Rust-1.91-compatible image
On current GitHub-hosted runners, windows-2025 no longer means the VS 2022 image: GitHub's June 2026 migration notice moved windows-2025 to Visual Studio 2026, while this job later runs cargo +1.91.0 build --target ...-pc-windows-msvc; Rust 1.91.0 was released before find-msvc-tools 0.1.5 added Visual Studio 2026 probing in its changelog, so these Windows source-build jobs can fail to locate link.exe/MSVC when they start on the new image. If the upstream build must stay pinned to Rust 1.91, leave these entries on windows-2022 or install/select VS 2022 explicitly.
Useful? React with 👍 / 👎.
| - runner: windows-2025 | ||
| target: x86_64-pc-windows-msvc | ||
| - runner: windows-2022 | ||
| - runner: windows-2025 | ||
| target: aarch64-pc-windows-msvc |
There was a problem hiding this comment.
Split the source-build cache by runner image
This moves the canary source-build producer to windows-2025, but .github/workflows/rusty-v8-release.yml still runs the same build-windows-source matrix on windows-2022 while using the identical rusty-v8-source-${{ matrix.target }}-sandbox-... cache key/path. actions/cache documents its cache version as derived from path/compression rather than the workflow or image, so these jobs can now restore each other's gn_out/sccache contents across different Windows/Visual Studio images; include the runner/toolchain in the cache key or migrate the release workflow in the same change to avoid reusing stale native build outputs.
Useful? React with 👍 / 👎.
Why
The V8 Windows source jobs need a runner image that can support the later Dev Drive setup.
What
Move the two V8 Windows source-build matrix entries from
windows-2022towindows-2025.Manual validation
yq.Stack