From ea5c3ccc51bad9790bb9d583f0376539339d98dc Mon Sep 17 00:00:00 2001 From: Gary Hsu Date: Mon, 10 Aug 2026 16:10:34 -0700 Subject: [PATCH] Build the Windows and UWP CI jobs with Visual Studio 2026 Both workflows were the last pins left on windows-2022 while macOS already runs macos-26, so the Windows toolchain was the one place CI could not see compiler drift coming. Pins the explicit windows-2025-vs2026 label rather than windows-latest or windows-2025. Those resolve to Windows Server 2025 but not to a fixed Visual Studio version -- actions/runner-images#14004 reports the windows-2025 label serving the VS2026 image, and #14140 reports two jobs in a single run landing on different images and breaking MSVC LTCG linking. --- .github/workflows/build-uwp.yml | 3 ++- .github/workflows/build-win32.yml | 8 ++++++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/.github/workflows/build-uwp.yml b/.github/workflows/build-uwp.yml index 9a179079..ebe92c95 100644 --- a/.github/workflows/build-uwp.yml +++ b/.github/workflows/build-uwp.yml @@ -12,7 +12,8 @@ on: jobs: build: - runs-on: windows-2022 + # See build-win32.yml for why the image label is pinned explicitly. + runs-on: windows-2025-vs2026 timeout-minutes: 15 steps: - uses: actions/checkout@v5 diff --git a/.github/workflows/build-win32.yml b/.github/workflows/build-win32.yml index 0e840215..23811282 100644 --- a/.github/workflows/build-win32.yml +++ b/.github/workflows/build-win32.yml @@ -12,9 +12,13 @@ on: jobs: build: - runs-on: windows-2022 + # Explicit image label rather than `windows-latest` or `windows-2025`: those + # resolve to Windows Server 2025 but their Visual Studio version is not fixed + # (actions/runner-images#14004, #14140), and a run whose jobs land on + # different images is exactly the kind of failure CI should not have. + runs-on: windows-2025-vs2026 # Hermes pulls in a large LLVH/Boost.Context/BCGen chain through - # `hermesvm_a`; on `windows-2022` the full configure+build comfortably + # `hermesvm_a`; the full configure+build comfortably # exceeds the standard 15-minute window. Keep other engines snappy. timeout-minutes: ${{ inputs.js-engine == 'Hermes' && 60 || 15 }} steps: