GitHub Actions windows-11-arm 要換 VS2026？先用新 Runner label 驗證

2026-08-29

伺服器

GitHub Actions

/

/

/

/

如果 workflow 使用 GitHub Actions 的 Windows ARM64 runner，現在應該把 Visual Studio 版本當成即將發生的相容性變更處理。GitHub 已宣布 windows-11-arm 會在 2026 年 9 月 21 日至 30 日逐步改用 Visual Studio 2026；依賴 VS2022、特定 SDK 或原生編譯工具的 job，可能在 image 更新後才暴露問題。

比較穩妥的做法是先把代表性 workflow 暫時改到明確的 windows-11-vs2026-arm label，驗證編譯、測試和封裝，再決定是否讓正式工作跟著 windows-11-arm 遷移。不要把目前 label 當成永遠固定在 VS2022 的承諾。

你要跟著 migration，還是先釘住工具鏈？#

Runner label	適合用途	需要知道的事
`windows-11-arm`	追蹤 GitHub 管理的 Windows ARM image	會在公告時程內逐步轉到 VS2026
`windows-11-vs2026-arm`	立即測試 VS2026 ARM64 image	用明確 label 把新工具鏈納入驗證
`windows-2022`	仍需 Windows x64 與既有 VS2022 工具鏈	不是 ARM64 runner，原生相容性要重新評估

上表的重點是「image 與架構同時選」。如果專案必須使用 ARM64 編譯結果，不能只因為 VS2022 還沒準備好就改用 x64 runner；反過來，若只是測試 Windows 相容性且沒有 ARM 原生需求，windows-2022 可能是暫時選項，但它代表另一種架構和工具鏈。

先建立一個可手動觸發的驗證 workflow#

先不要一次修改所有 production job。建立只在 workflow_dispatch 執行的檢查，讓團隊能在 VS2026 image 上取得作業系統、架構、image 版本和基本 .NET／MSBuild 資訊：

1
name: Windows ARM toolchain check
2

3
on:
4
  workflow_dispatch:
5

6
jobs:
7
  check:
8
    runs-on: windows-11-vs2026-arm
9
    steps:
10
      - name: Show runner
11
        shell: pwsh
12
        run: |
13
          $env:PROCESSOR_ARCHITECTURE
14
          [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
15
          $env:ImageVersion
16

17
      - name: Check toolchain
18
        shell: pwsh
19
        run: |
20
          dotnet --info
21
          if (Get-Command msbuild -ErrorAction SilentlyContinue) {
22
            msbuild -version
23
          } else {
24
            Write-Error "msbuild was not found on PATH"
25
          }

這只是最低限度的 image 檢查，不是完整相容性測試。msbuild 不一定在 PATH；若專案依賴 Visual Studio 的特定元件，應依 runner image 文件找到實際安裝位置，並用真實 build 指令驗證，而不是因為 dotnet --info 成功就判定整個 workflow 沒問題。

用代表性 job 驗證，不只檢查版本字串#

至少挑一個真正會用到下列路徑的 workflow：

.NET 或 C++ 編譯，包含專案指定的 SDK、PlatformToolset 或 Windows SDK。
Node.js 原生模組安裝，例如 node-gyp、Rust／C++ addon 或需要預編譯 binary 的套件。
單元測試與整合測試，特別是會載入 Windows DLL、檔案權限或路徑格式的測試。
產出安裝包、CLI binary 或要上傳到 release 的封裝步驟。

測試結果要連同 Node、.NET、MSBuild、Windows SDK、套件 lockfile 與 image version 保存。這樣 image 真正切換後，才能分辨是 runner 更新造成的差異，還是依賴本身同時改版。

常見風險包括：

風險	會看到的現象	建議檢查
VS2022 專用 PlatformToolset	C++ 專案找不到工具集或編譯旗標不相容	`.vcxproj`、CMake preset、Windows SDK
原生套件沒有 ARM64 binary	安裝時 fallback 到本機編譯，或直接失敗	lockfile、node-gyp、Rust target
依賴 x64 第三方 binary	測試載入 DLL 時才失敗	binary 架構、載入路徑與打包清單
image 內工具位置改變	`where` 或 PATH 找不到命令	runner-images 文件與實際 `Get-Command`

正式切換前做一次雙 label 比對#

可以在短期內用 matrix 讓同一組測試分別跑在 windows-11-arm 與 windows-11-vs2026-arm。若測試時間或 ARM runner 使用量不允許全量比對，至少固定一組 smoke test，涵蓋編譯、原生模組、測試和封裝四個階段。把差異分類成「預期的版本變更」或「必須修正的相容性問題」，不要只用整個 job 的綠／紅判斷。

正式 workflow 可以先使用新 label，再把原本的 label 保留在手動回復分支，但回復也要有截止日。若 workflow 真的要求 VS2022，應明確記錄這項需求和可用 runner，而不是等待 windows-11-arm 的 image 更新後才從排隊或編譯錯誤中推測發生了什麼。

另外，GitHub-hosted runner image 會隨更新週期變化，第三方 actions 也可能有自己的架構支援範圍。建議把 runner label、工具版本輸出和失敗 log 放進 CI 診斷資訊；若你管理的是自架 runner，則要另外盤點 runner image 和更新策略，參考 GitHub Actions 自架 Runner 版本盤點清單的維運方式。

結論很簡單：現在就用 windows-11-vs2026-arm 跑一組真實 smoke test，確認專案是否能接受新工具鏈；9 月 21–30 日期間再觀察 windows-11-arm 的正式遷移。架構需求與 VS 版本需求若不同，應分別做決策。