截至 2026 年 9 月 2 日，GitHub Actions 已自 2026 年 6 月 16 日起讓 Runner 預設使用 Node 24，Node 20 臨時回退只維持至 2026 年 9 月 23 日。企業不應等待 Node 20 正式移除，應立即在隔離的 Mac 節點啟用 Node 24，完成 Action、Runner、macOS 與 Xcode 雙軌驗證，再分批切換生產節點。相關時程以GitHub Node 20 棄用公告及最低 Runner 版本執行時間表為準。
這篇文章適合三類讀者：管理 self-hosted runner 的平台團隊、負責 iOS 發布的研發效能團隊，以及需要規劃 Mac 節點替換容量與業務連續性的 IT 負責人。若團隊只使用 GitHub 託管 Runner，本文的 Mac 節點驗收部分可略讀；若生產流程依賴自托管 Mac，則不宜跳過隔離試點。
注意： Node 24 遷移涉及三個不同層次：JavaScript Action 內置的執行時、專案本身使用的 Node.js 版本，以及 Actions Runner 應用程式版本。只升級其中一項，不能宣稱整條 CI 已完成升級。
第一步：遷移啟動日先建立資產基線
遷移的第一個工作不是修改 YAML，而是找出哪些工作流真正會執行 JavaScript Action。企業應按「組織／倉庫／工作流／Action 版本／Runner 版本／macOS／CPU 架構」建立資產表，並額外記錄是否持有簽名憑證、是否連接私有套件來源，以及目前所屬 Runner Group。
建議至少收集以下資料：
- 每個工作流引用的 Action 名稱、版本或固定提交；
- Action 是 JavaScript、Docker 還是 composite 類型；
- self-hosted runner 的標籤、作業系統、架構與應用程式版本；
- 工作流最近的失敗步驟、警告訊息與執行時間；
- Xcode、依賴管理工具、Keychain 與快取目錄；
- 生產簽名節點、測試節點與一般建置節點的權限邊界。
Self-hosted Runner REST API可用來核對 Runner 的名稱、標籤、作業系統與狀態；Workflow Runs REST API則可協助按倉庫整理執行結果。API 資料應與工作流日誌及節點本機記錄交叉核對，因為「目前在線」不等於「具備 Node 24 生產條件」。
先分離三種版本責任
專案的 actions/setup-node 所設定的 Node.js 版本，主要影響建置腳本或測試程式；它不會自動改變 JavaScript Action 的內置執行時。相反地，Action 的 runs.using 與其發布版本，才是 Node 20 到 Node 24 遷移時的直接檢查對象。
Runner 應用程式又是另一層。它負責接收任務、準備執行環境及回報狀態，不代表所有舊版 Action 都已經相容。因此，資產表中不能只留一欄「Node 版本」，而要將三個版本分欄保存。
第二步：第一小時在隔離節點強制執行 Node 24
試點節點應是沒有生產簽名私鑰、沒有正式發布權限的 Mac Runner。其 macOS、CPU 架構、Xcode 與依賴快取應盡量接近預定的生產節點，但工作流的輸出要導向測試制品庫，避免試點直接發布應用程式。
依官方公告提供的遷移方式，可在指定工作流或試點環境提前讓 JavaScript Action 使用 Node 24。實際變數名稱、適用範圍與撤銷方式，必須以官方 Node 24 遷移說明的最新內容為準，不宜把臨時回退變數寫成長期設定。
隔離試點至少要跑一條完整基線流水線：
- 取得公開及私有程式碼；
- 還原快取並安裝依賴；
- 執行自訂 JavaScript Action；
- 執行 Xcode 建置與測試；
- 產生歸檔並驗證制品；
- 執行測試簽名或受控簽名；
- 將日誌、狀態與輸出檔保存到指定位置。
這裡的目標不是測量單次速度，而是確認每一個交付環節都能在 Node 24 下重現。若只看到 xcodebuild 成功，卻沒有測試私有依賴、快取、制品上傳和自訂 Action，仍只能標記為「部分通過」。
第三步：首日完成 Action、Runner 與 macOS 修復
完成基線後，先處理仍使用舊執行時的官方或第三方 Action。若工作流固定到某個提交版本，固定本身可能阻止安全更新；團隊應記錄變更原因，建立新的提交審查與回歸測試，而不是直接把所有版本改成浮動標籤。
Runner 應用程式則按照Actions Runner Releases與企業組織下載頁面核對。驗證項目包括：
- 新 Runner 是否能正確註冊到原有組織或 Runner Group；
- 自動更新是否完成，或是否需要受控手動升級；
- 服務重啟後是否仍保持註冊狀態；
- 節點重開機後是否能重新接收任務；
- 舊標籤是否意外把未驗證工作流導向試點節點。
配置 self-hosted runner 服務的官方文件適合用來核對服務啟動、停止與狀態檢查。若舊 macOS 不在現行 Runner 支援範圍內，處理順序應是升級系統、替換節點或退出生產池，而不是永久依賴 Node 20 回退。
第四步：首次生產驗證要覆蓋 Xcode 與簽名閉環
生產驗證必須使用實際專案，而不是另外建立一個只會編譯的示範倉庫。對 iOS CI 而言，以下環節缺一不可：
- 私有 Git 依賴與套件來源的憑證；
- Xcode 版本、SDK 選擇與建置設定；
- 測試執行、測試報告與失敗重試；
- archive、exportOptions 與制品上傳；
- Keychain 解鎖、臨時簽名檔及憑證權限；
- 代理伺服器憑證、Shell 腳本與環境變數；
- 快取目錄的擁有者、清理策略與跨任務污染。
簽名發布應在受控節點獨立驗證。試點節點不應因為要測試完整流程，就取得超出本次任務所需的生產私鑰或發布權限。可先以測試簽名完成流程，再由具備最小權限的生產節點進行一次受審批的發布驗證。
企業也應參考GitHub Actions 安全使用指南，重新檢查第三方 Action 的來源、權限範圍、秘密資料暴露風險及工作流修改審查。Node 24 遷移不是單純的版本替換，亦是一次檢查 Action 供應鏈與簽名隔離的窗口。
經驗提醒： 若 Node 24 試點只在公開專案上成功，不能推論企業生產流程已相容。私有依賴、代理憑證、Keychain 和固定提交版本，往往才是實際切換時最先暴露差異的地方。
第五步：首週採用雙軌路由與回退演練
遷移期間應保留已驗證的生產池，同時建立 Node 24 試點池，使用 Runner Group 或標籤讓倉庫分批轉流。分批條件可以包括：工作流類型、產品線、是否需要簽名，以及失敗後的業務影響。
回退設計要驗證四種故障，而不是只測試「把變數改回去」：
- Action 在 Node 24 下啟動失敗；
- Runner 更新中斷或服務未能重新啟動；
- Mac 重啟後未恢復註冊；
- 試點任務失敗後能否重新路由至生產池。
回退節點必須保持可用但不可無限期保留。若回退重新引入已淘汰的 Node 20，應為它設定明確的退出條件、負責人與最後使用日期。對於無法在期限前升級的舊 Mac，替換新節點通常比持續維護臨時例外更容易稽核。
GitHub 已確認 Node 20 臨時回退只到 2026 年 9 月 23 日；GitHub Enterprise Cloud 的自托管 Runner 最低版本全面強制執行計劃自 2026 年 9 月 25 日開始，但具體最低版本與漸進發布狀態仍應以組織下載頁面及官方公告為準。
中段決策表：把節點狀態轉成處置動作
| 節點或工作流狀態 | 遷移處置 | 是否可留在生產池 | 必須留下的證據 |
|---|---|---|---|
| Action、Runner、macOS 均符合條件，完整流水線通過 | 轉入 Node 24 生產池 | 可以 | 工作流日誌、Runner 狀態、簽名驗證 |
| Action 尚未更新，但可在隔離池通過回歸測試 | 暫留試點池並安排版本修復 | 不宜直接放量 | 版本提交、失敗與通過紀錄 |
| Runner 應用程式不符合組織最低版本 | 升級服務或替換節點 | 不應作為長期生產節點 | 版本核對、重啟及重新註冊結果 |
| 舊 macOS 不在支援範圍 | 升級系統、退出生產池或替換 Mac | 不應保留為正式回退 | 系統支援核對與替換計劃 |
| 需要生產簽名且尚未完成權限隔離 | 先用測試簽名驗證 | 不可以 | Keychain、秘密資料與審批紀錄 |
| Node 24 試點失敗但生產池仍穩定 | 暫停該倉庫轉流，保留雙軌 | 原生產池可以 | 失敗日誌、路由紀錄與責任人 |
第六步：期限前完成准入、切換與容量安排
在官方強制日期前，平台團隊應凍結未驗證的舊 Action，並為每個生產 Runner 建立准入紀錄。准入表至少包括 Runner 應用程式狀態、macOS 支援條件、架構、核心流水線結果、簽名隔離、重啟恢復及負責人。
若舊節點不能升級，容量決策不應只看目前在線數量，還要看待遷移倉庫數、試點通過率、節點替換所需時間及失敗後的回退需求。短期內可把新遠程 Mac 放入隔離試點池，先驗證真實工作流，再決定需要替換的節點數量與租用週期；這比在截止日前一次改動整個生產池更容易控制風險。
若團隊正在整理自托管 Mac Runner 上線驗收方法，可將本次 Node 24 准入條件加入既有驗收表；需要比較按月採購與使用成本時，再參考Mac 方案價格頁。對於無法在企業既有硬體上完成升級的團隊，遠程 Mac 租用方案可先作為隔離替換節點，但仍須由企業自行完成權限與流水線驗證。
企業 FAQ：期限、回退與節點替換
GitHub Actions 移除 Node 20 後，哪些工作流會失敗？
最直接受影響的是使用 JavaScript Action 的工作流，包括 checkout、快取、制品上傳與自訂 Action。工作流即使主要步驟是 Shell 或 Xcode，也可能在前後置 Action 失敗，因此應按完整執行鏈路盤點，而不是只搜尋 Node.js 建置步驟。
自托管 Mac Runner 如何測試 Node 24 相容性？
應選沒有生產簽名憑證的隔離 Mac Runner，使用官方遷移開關執行基線工作流，涵蓋依賴、快取、自訂 Action、Xcode、測試、archive、簽名與制品上傳。測試報告要保存執行環境與回退結果，單次編譯成功不足以作為准入證據。
舊版 GitHub Action 能否繼續在 Node 24 上運行？
不能直接假設。需要查閱 Action 的發布說明與執行時宣告，確認固定提交是否包含相容修復，再在試點池執行實際工作流。若第三方 Action 長期沒有維護，應準備替代實作或將該工作流暫留在受控回退路徑。
Mac Runner 升級失敗時如何保留生產回退節點？
將已驗證的生產池與 Node 24 試點池分開，以標籤或 Runner Group 控制轉流。升級失敗時撤回倉庫路由，而不是在同一台 Mac 上反覆覆蓋版本；同時演練服務重啟、重新註冊、任務重新排程及回退節點的退出期限。
Node 24 遷移是否需要同時升級 macOS 和 Runner？
不必然同時執行，但必須共同驗證。先對照 Runner Releases、組織下載頁面及自托管 Runner 文件，確認舊 macOS 是否仍受支援；若不符合條件，應升級系統、替換 Mac 或退出生產池，不能把臨時回退當作永久方案。
生產准入前的可勾選清單
- [ ] 已分開記錄 Action 內置執行時、專案 Node.js 與 Runner 應用程式版本。
- [ ] 已透過 API、工作流日誌及節點記錄完成倉庫與 Runner 資產盤點。
- [ ] 已在不持有生產簽名憑證的隔離 Mac 上啟用 Node 24 試點。
- [ ] 已測試 checkout、快取、私有依賴、自訂 Action 與制品上傳。
- [ ] 已完成 Xcode 測試、archive、測試簽名及受控生產簽名驗證。
- [ ] 已核對 macOS、CPU 架構、Runner 版本及服務重啟後的註冊狀態。
- [ ] 已用 Runner Group 或標籤完成雙軌路由，而非一次切換所有倉庫。
- [ ] 已演練 Action 失敗、Runner 更新中斷、Mac 重啟及任務重新排程。
- [ ] 已為舊節點寫明升級、替換或退出生產池的截止條件。
- [ ] 已由責任人確認 Node 20 回退不會被當成長期運行方案。
結尾前的方案判斷：保留舊 Mac 還是替換遠程節點
如果現有 Mac Runner 能在期限前完成 Runner、macOS、Action 和 Xcode 全鏈路驗證，自行維護生產池通常能保留既有權限與硬體整合；但舊設備可能受限於系統支援範圍、升級停機窗口、重啟後無人值守恢復，以及簽名環境難以隔離。若企業仍以這類節點承擔所有生產工作，Node 20 回退期限過後，例外處理可能直接變成交付風險。
對於無法及時升級、需要短期增加試點容量，或必須先把新環境與正式簽名節點分開的團隊，租用 RUVCLOUD 的遠程 Mac 可先建立隔離 Node 24 節點，再用真實流水線決定替換數量與租用週期。這種做法不會替代企業的安全審查，但可避免在舊 Mac 上反覆冒險升級，並為截止期限前的雙軌切換提供可操作的緩衝。
如需臨時 Mac CI 試點或替換不相容節點，可先查看 RUVCLOUD 的遠程 Mac 方案，再依照本文准入清單完成 Runner、Xcode、簽名與重啟恢復驗證。
最後更新於 2026 年 9 月 2 日；日期與遷移行為核實自 GitHub Node 20 棄用公告、最低 Runner 版本執行時間表、自托管 Runner 文件、REST API 文件及 Actions Runner Releases。