GitHub 官方公告指出，2026 年 9 月 23 日起，GitHub Actions Runner 已移除 Node 20 JavaScript Action 執行時，改用 Node 24；因此，排查 Mac CI 時先確認失敗的是 Action 執行時，還是你的專案自行使用的 Node.js，再更新相關 Action 並驗證相容性。若你維護自託管 Mac Runner，也要單獨核對 macOS 版本，不要一開始就換硬體或擴充節點。GitHub 官方變更公告

本週建議動作：先從失敗工作流程找出 Action 名稱、版本與初始化錯誤；在隔離工作流程測試支援 Node 24 的更新版本，再以完整建置或測試結果決定是否放行。GitHub 已說明舊執行時移除與新執行時的系統限制，本文的核對依據為官方變更公告及GitHub Actions 文件。

適合閱讀的對象：
企業 IT 負責人：需要界定受影響的 Mac CI 工作流程與復原優先級。
平台工程師：維護自託管 Runner、共用 Action 或組織級工作流程範本。
iOS/macOS 發布負責人：要確認關鍵建置、測試與發布工作真正恢復。

最後更新於 2026 年 10 月 21 日；已依 GitHub 變更公告、Action 中繼資料文件及 Runner 文件核對執行時與相容性資訊。

01

先拆解故障指標：執行時、系統相容性與驗收證據

Node 20 下線指的是 GitHub Actions Runner 用來執行 JavaScript Action 的 Node.js 執行時變更。它不代表 Runner 上安裝的 Node.js、工作流程自行設定的 Node.js 版本，或你的應用程式執行環境也一併被移除。若把兩層混為一談，直接改專案版本，可能增加變更風險，卻沒有碰到真正故障點。GitHub 對 Node.js 工作流程的說明與執行時公告描述的是不同設定層。

常見的誤判可以從以下指標拆開：

  • Action 初始化失敗：先檢查失敗的 JavaScript Action 及其執行時宣告；它可能在工作流程進入建置命令前就無法啟動。
  • 應用程式相依套件或建置失敗：確認工作流程以何種方式安裝或選用專案 Node.js。不要因錯誤訊息提及 Node，就直接改 Runner 上的工具版本。
  • 少數工作流程失敗：找出失敗工作流程實際引用的 Action 版本、複合 Action 內的巢狀引用，以及組織範本是否另行指定版本。共用範本可能讓同一個舊引用擴散到多個儲存庫。
  • 只有特定 Runner 失敗：比對 macOS 版本與處理器架構。這是環境相容性線索，不足以單獨證明硬體本身故障。
  • Runner 顯示在線、工作仍失敗：在線狀態只證明 Runner 可接收工作，不能證明 Action 初始化、Xcode 建置或發布流程已成功。

若工作流程使用 actions/checkout 等現成 Action、自訂 JavaScript Action，或包在複合 Action 裡的其他 Action，排查時要追到實際執行的版本，而不是只看工作流程表面上的一行引用。GitHub 工作流程語法也支援以不同方式引用 Action 和工作流程，因此應連同工作流程定義一併核對。工作流程語法參考

02

如何確認失敗的是 Action 執行時，而非專案 Node.js？

先看錯誤發生在哪個階段，再把日誌裡的 Action 名稱和工作流程引用對起來。Action 的 action.yml 或 action.yaml 中，runs.using 欄位會標示 JavaScript Action 使用的 Node.js 執行時；依 GitHub 文件，這是判定 Action 執行時的重要線索。Action 中繼資料語法文件

接著沿著呼叫關係追查：

  • 查看失敗步驟呼叫的 Action 與固定或浮動版本標籤。
  • 若呼叫的是複合 Action，進入其步驟定義，逐一確認內部使用的 Action。
  • 對自訂 JavaScript Action，檢查原始碼中的執行時中繼資料，以及目前工作流程實際下載的發布版本。
  • 對照工作流程中的 Node.js 安裝與選用步驟。若錯誤出現在該步驟之後，才進一步判斷專案 Node.js 或相依套件是否有問題。
  • 將初始化訊息、錯誤發生步驟、Runner 系統和架構一起記錄，避免只保留最後一行錯誤。

建立 JavaScript Action 時，執行時宣告與 Action 程式碼是不同檢查點；只更新程式碼、不發布工作流程實際引用的版本，使用者仍可能執行舊內容。GitHub 的JavaScript Action 建立指南提供 Action 結構與中繼資料的核對依據。

注意：若你在舊文件或內部操作手冊中看到暫時切回 Node 20 的設定，不要把它當成現行修復路徑。官方已公告移除舊執行時，應以目前公告和 Runner 實際錯誤為準。

03

Node 24 相容性核對：macOS 版本、架構與 Runner

Node 24 的作業系統限制需要和 Action 自身問題分開診斷。GitHub 公告指出，Node 24 不相容於 macOS 13.4 及更早版本，也不正式支援 ARM32。官方執行時公告這些界線不能推演成「所有 Apple Silicon Mac 都會故障」；要核對的是實際 Runner 系統版本、處理器架構及失敗的 Action。

核對指標 要找的證據 判讀方向
Action 執行時 Action 中繼資料中的 runs.using、初始化日誌 確認實際執行時與所用 Action 版本；不要以專案 Node.js 設定代替
macOS 版本 Runner 的系統版本與工作日誌 若為 macOS 13.4 或更早版本，評估 Node 24 不相容的可能性
處理器架構 Runner 主機架構與工作執行資訊 若為 ARM32，需按官方支援邊界處理；不要將此限制泛化到所有 Apple Silicon 主機
Action 版本 工作流程、複合 Action、組織範本中的引用 判斷是否有舊版或未更新的 JavaScript Action
任務驗收 初始化、相依套件、Xcode 建置、測試及發布結果 以完整關鍵任務驗收，不以 Runner 在線或單一步驟成功代替

查看 Runner 分配方式時，也要確認工作流程的標籤或選擇條件是否把任務導向預期主機。GitHub 說明了如何選擇工作流程作業的 Runner；自託管環境則須一併盤點主機維護責任與系統狀態，並依自託管 Runner 文件檢查管理方式。

實務上，自託管 Mac Runner 容易有幾種隱性成本：系統升級與安全維護由團隊承擔；共享節點上的工作流程引用可能分散在儲存庫、複合 Action 與組織範本；單一節點的架構或系統限制會影響送到它的工作。這些成本都不能只靠「Runner 在線」或更換硬體來處理，必須先明確標示節點支援範圍，並讓工作流程路由與實際環境相符。

04

如何更新舊 JavaScript Action 並完成驗收？

先選擇已明確支援 Node 24 的 Action 版本，再在隔離的工作流程驗證其行為。不要一次更新所有共用引用，也不要只憑版本標籤判定相容；輸入參數、輸出值與錯誤處理方式都要符合原本工作流程的依賴。

建議依序執行：

  • 盤點引用來源：搜尋工作流程檔、複合 Action 和組織級範本，記錄 Action 名稱、目前版本與被哪些關鍵工作流程使用。
  • 確認更新內容：查閱候選版本的發布說明與中繼資料，確認它使用受支援的執行時，並核對輸入、輸出及失敗處理是否改變。
  • 建立隔離驗證：先在非正式或受控工作流程替換 Action 版本，保留原設定，避免未驗證變更直接影響發布路徑。
  • 核對 Runner 環境：記錄 macOS 版本與處理器架構。若系統落在官方限制範圍內，將它當成獨立問題處理，而非假定更新 Action 就會排除系統不相容。
  • 重跑完整關鍵任務：確認 Action 初始化、相依套件安裝、Xcode 建置或測試等實際步驟，再驗證發布工作流程需要的後續結果。
  • 分批套用與留存記錄：將驗證通過的版本更新到其他工作流程，保留 Action 版本、Runner 資訊、日誌連結與驗收結果，方便日後追查。

以一個常見的團隊案例來看：若同一份組織範本被多個 iOS 專案共用，範本內一個舊 Action 引用就可能讓不同工作流程同時出現初始化錯誤。此時，先在隔離分支確認更新版本能否完成完整建置與測試，再推廣範本，比直接調整所有 Mac 節點更容易定位變更的影響範圍。這是排查方式的示例，不代表任何特定環境已通過驗收。

05

放行決策：依證據選擇更新、隔離或調整環境

依照下列條件處置，讓 Runner 系統限制、Action 相容性與建置驗收各自有對應證據：

  • 若錯誤指向 JavaScript Action 執行時，而且 Runner 系統符合支援條件：選擇更新到支援 Node 24 的 Action 版本，先隔離驗證，再逐步推廣。
  • 若問題來自自訂 JavaScript Action：由維護者調整執行時宣告、檢查程式碼相容性，發布新版本後再更新工作流程引用。只改 Runner 上專案 Node.js 的版本，不能代替這項修正。
  • 若自託管 Runner 使用 macOS 13.4 或更早版本：先核對 Action 初始化日誌與實際系統環境；若證據符合官方限制，再評估受支援的 macOS 環境或不同 Runner。不要在沒有證據時把所有 Mac CI 故障歸咎於硬體。
  • 若只有單一步驟成功，或 Runner 只是顯示在線：暫緩關鍵發布工作放行，直到同一條工作流程完成建置、測試及必要的發布驗收。
  • 若關鍵工作流程全部通過，但其他範本尚未核對：只放行已驗收範圍，將未核對引用保留在隔離或分批更新清單中。

放行紀錄至少應寫明受影響的 Action 版本、Runner 系統與架構、工作流程引用位置、驗證結果，以及由誰負責後續更新。之後若 GitHub 改變執行時政策或相容邊界，就依這些記錄重新核對，而不是沿用已過時的處置假設。

如果你的 Mac CI 已由固定自託管主機承載，這種方式的優點是團隊能自行管理環境與排程；代價則是要持續負責系統更新、節點維護與容量閒置或排隊等問題。若故障證據顯示需要的是不同、受支援的 macOS 環境，而不是改專案 Node.js，你可以評估按需使用遠端 Mac，並先核對實際交付環境、架構與工作負載相容性。VpsMesh 的遠端 Mac 方案資訊及Mac mini 租用價格頁可供你比較；若團隊需要長期固定負載，或工作流程仰賴特定實體介面，先維持自有主機可能更合適。關鍵仍是先完成 GitHub Actions Node 20 Mac CI 故障排查，再依驗收結果決定是否調整承載環境。