GitHub Actions 自託管 Mac Runner 版本過期怎麼辦？2026 修復指南

強制執行日期與影響範圍要先核實：GitHub Enterprise Cloud 的自託管 Runner 版本強制執行已於 2026 年 9 月 29 日開始；低於 2.329.0 的 Runner 不能註冊或重新註冊。帶資料駐留的 GitHub Enterprise Cloud 已於 2026 年 7 月 31 日進入強制執行。上述日期及適用產品以官方公告為準。

2.329.0 是註冊門檻，不是永久執行工作流程的最低版本。工作流程執行支援會隨新 Runner 版本推進，某一版本何時停止接單或執行，應使用官方退役 API 查核；不要把兩類門檻合併成一條固定規則。GitHub Enterprise Server 不受上述公告影響，不能直接套用 Enterprise Cloud 的日期。

先建立可供維運人員執行的清冊，而不是只看管理介面上有幾台 Runner 在線。每筆資料至少記錄節點識別、Runner 版本、在線與忙碌狀態、註冊範圍、作業系統、工作流程用途、自動更新設定，以及節點由何種映像或部署流程建立。倉庫、組織與企業層級都要納入，避免只整理到單一專案。

接著將清冊與實際主機版本核對。可從 Runner 管理介面或官方支援的管理方式確認版本，並在節點端保存版本輸出或相關記錄；狀態與版本不一致時，先查清節點是否已更新但未重新連線，或資產清冊是否仍指向舊主機。GitHub 的自託管 Runner 管理指南可作為管理 macOS 節點的官方參考。

盤點時特別標記三種容易漏掉的來源：

• 預設自動更新的節點：確認節點能連到更新服務，並在維運記錄中核對實際版本，而非假設自動更新必定成功。
• 停用自動更新的節點：找出負責人工或自動部署更新的人員、排程與驗收方式；沒有明確責任人的節點要列為高風險。
• 由映像、容器或部署自動化建立的節點：追溯安裝腳本、基礎映像、快取範本與容器映像，否則替換節點時可能再次註冊舊版。

將清冊中的 Runner 版本逐一與官方退役 API 回應對照，記錄註冊支援、工作流程執行支援及相應截止狀態。GitHub 的Runner 版本退役 REST API 文件是查詢依據；API 回應應與節點識別及資產資料關聯，方便後續追蹤。

這一步要把四種狀態分開記錄：版本能否註冊、是否仍支援執行工作流程、管理介面是否顯示在線，以及工作流程是否實際成功。某節點在線，只能表示它目前仍與控制端保持可見狀態，不能據此推斷它一定能接下新工作或完成既有流水線。

注意：不要把 2.329.0 寫入政策後就停止查核。它是公告所列的註冊門檻；工作流程執行支援須依當前退役狀態核實，且要在 GitHub 更新政策或 API 行為後重新檢查。

先按風險和用途選擇升級方式，再開始修改生產建構池。下表可用來確定節點的處理順序。

建議按以下順序操作：

1. 選定試點節點：從非關鍵 Mac CI Runner 開始，避開正在承擔發布或高優先級工作流程的節點。
2. 更新來源而非只更新主機：同步檢查安裝腳本、基礎映像、容器映像與快取範本，確保新建節點不會重新帶入舊 Runner。
3. 確認更新路徑可用：對啟用自動更新的節點，確認它能存取更新服務；對停用自動更新的節點，依維護程序部署版本並留下記錄。GitHub 的自託管 Runner 文件說明 Runner 更新與維護要求。
4. 逐批處理節點：每批更新後確認版本、在線狀態與忙碌狀態，再開始下一批；若更新失敗或工作流程排隊，先暫停擴大變更。
5. 設定可執行的回退條件：例如 Runner 更新後無法接單、工具鏈異常或目標工作流程失敗時，停止該批次，回退映像或工具鏈設定，並保留受支援的 Runner 版本。
6. 記錄變更證據：保存更新前後版本、API 查詢結果、工作流程連結、錯誤記錄和處置負責人，供稽核與後續節點更新參考。

Runner 版本太舊，會立即停止執行工作流程嗎？

不一定。註冊或重新註冊的版本門檻，與既有節點執行工作流程的支援狀態是不同規則；後者會隨新版推進。請依官方退役 API 查詢版本狀態，再以真實工作流程驗證。節點在線或尚未出現錯誤，都不能替代退役狀態檢查。

2.329.0 同時是註冊與執行工作流程的最低版本嗎？

不是。公告將 2.329.0 列為 GitHub Enterprise Cloud 的註冊與重新註冊門檻，並沒有把它定義為永久執行工作流程的最低版本。現有節點還要比對動態退役資訊，避免只升到註冊門檻後便停止維護。

關閉自動更新後，維護流程要包含什麼？

至少要明確指定維護責任人、Runner 版本檢查方式、更新部署來源、試點驗收和回退條件。若節點由映像或部署自動化建立，也要同步更新來源範本。回退可以恢復相容的映像或工具鏈，但不能退回已不受支援的 Runner 版本。

怎麼查特定 Runner 版本的退役時間？

使用 GitHub 官方 Runner 版本退役 REST API，按版本核對註冊及工作流程執行支援狀態，並將查詢結果連回節點清冊。對即將到期的版本安排升級與驗收；保留查詢日期、回應和變更記錄，才能在政策改動後辨認哪些節點需要重新處理。

Runner 更新完成後，先用實際工作流程驗收，而不是只確認服務啟動或節點重新顯示在線。至少選取會經過團隊日常路徑的 iOS CI/CD 任務，確認 Runner 能接單、Xcode 等工具鏈可用、建構和測試結果符合預期。若任務涉及簽章或發布，應另行核對對應權限、憑證使用方式及端到端結果；不可把一般建構成功當成發布流程已驗收。

若出現排隊或失敗，依序核對 Runner 版本及退役狀態、節點是否忙碌、更新服務連線、工具鏈設定與工作流程記錄。GitHub 的Runner 監控與故障排除文件可協助定位管理端與工作流程端的問題。故障未釐清前，先停止該批次變更，避免同一錯誤透過映像或自動化擴散到整個建構池。

將版本檢查納入日常維運：定期以官方 API 查退役狀態，與資產清冊比對並依團隊維護流程設定提醒；新 Runner 上線及映像更新時，也執行相同檢查。告警應指向明確負責人，並說明自動更新失敗、更新服務不可達、工作流程排隊或建構失敗時的處理與升級條件。若團隊需要以遠端主機補充升級期間的臨時建構容量，可先閱讀遠端 Mac 使用與管理說明，並依實際工作負載評估。

如果目前方案是單靠固定版本的自有 Mac，常見限制是硬體汰換與維護需要內部人力、臨時擴充要等待採購，以及不同節點的映像容易逐漸偏離；若以一般雲端主機替代，也不能直接取代需要 macOS 的真實 Mac 建構環境。團隊若只在升級或工作量高峰期間需要額外容量，可先完成 Runner 版本與流水線驗收，再評估按需租用遠端 Mac 是否適合作為過渡或彈性節點；若需要長期固定負載或實體介面，則應比較自有設備的維護與控制需求。需要臨時擴充時，可查看 NUKCLOUD 遠端 Mac 方案，並按實際需求確認服務與訂購資訊。