Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/v8-canary.yml
Original file line number Diff line number Diff line change
Expand Up @@ -314,9 +314,9 @@ jobs:
fail-fast: false
matrix:
include:
- runner: windows-2022
- runner: windows-2025
target: x86_64-pc-windows-msvc
- runner: windows-2022
- runner: windows-2025
target: aarch64-pc-windows-msvc
Comment on lines +315 to 318

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +315 to 318

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.


steps:
Expand Down
Loading