GitHub Actions Runner 版本過期怎麼辦？2026 Mac 升級清單

截至 2026 年 8 月 26 日，GitHub 已確認自託管 Runner 的最低版本執行機制，相關執行範圍與時間表應以官方最低版本公告為準。

症狀： Runner 顯示在線，但工作流程仍可能因版本要求而無法接收任務。
最快解法： 自動更新節點立即核驗更新鏈路；固定版本節點先建立備用 Mac，再灰度升級；大型節點池按測試、放量、回滾三階段執行。

最後更新於 2026 年 8 月 26 日；日期、最低版本執行範圍與更新行為核實自 GitHub Changelog、Self-hosted Runner 文件、官方 Runner 發布頁及帳戶內即時下載指引。

這篇升級清單適合哪些 Mac Runner 維護者

個人開發者： 你只有一台長期在線的 Mac Runner，最怕維護期間所有構建任務排隊。本文提供單節點保底與驗收順序。

小型研發團隊： 多個儲存庫共用簽名、快取與 Xcode 工具鏈，需要控制升級對測試及發布流水線的影響。

平台與 DevOps 團隊： 你負責固定版本、受限網路或批量節點，必須把版本盤點、灰度、審計和回滾變成可重複流程。

先分清在線狀態與可執行資格

GitHub Actions Runner 版本過期時，最容易誤判的訊號就是控制台仍顯示「在線」。這只證明節點能夠回報狀態，不能證明它符合目前的最低版本要求，也不能證明工作流程一定能被派送。

先檢查以下證據：

• GitHub 帳戶、組織或企業層級的 Runner 管理頁面。
• 節點實際顯示的 Runner 版本，以及帳戶內當日下載指引提供的版本。
• Runner 服務啟動與更新日誌，尤其是版本拒絕、下載失敗或權限錯誤。
• 工作流程中的 Runner 選擇器、固定標籤與任務派送結果。
• 官方最低版本公告是否已涵蓋你的管理層級。

不要把快取的搜尋結果、舊版安裝筆記或「節點在線」當作合格證據。GitHub 的執行安排可能分階段推進；已公布的未來測試日期與已生效限制，也必須分開記錄，不能混寫成同一項已生效規則。

若你要盤點多個節點，可以用自託管 Runner API 取得節點的作業系統、狀態、忙碌狀態與版本欄位，再與帳戶內下載指引交叉比對；欄位定義可參考 GitHub 自託管 Runner REST API 文件。

注意： 不要為了讓更新服務「先跑起來」而關閉 TLS 憑證驗證。這會掩蓋代理、憑證鏈或網路存取問題，也會削弱安裝包來源的可信度；若不得不做例外測試，必須寫明風險、時限與恢復方式。

單一 Mac 與共享節點：先保命，再升級

只有一台 Mac Runner 的個人開發者

單節點的目標不是「最快換上新版本」，而是升級失敗時仍能交付。維護前先保存：

• Runner 標籤、群組歸屬與工作流程路由條件。
• 工作目錄、快取策略、服務啟動設定及服務帳戶權限。
• Xcode、SDK、套件管理器與簽名憑證的可恢復資訊。
• 最近一次成功構建所使用的提交、歸檔及輸出位置。

如果這台 Mac 不能停機，先安排臨時托管任務，或建立一台隔離的遠端 Mac 作為保底節點。保底節點不必一開始承接全部工作，但必須能完成相同的註冊與最小構建鏈路。

升級後依序驗收：節點重新註冊、標籤能被正確路由、Mac 重啟後服務自動恢復，最後執行一個真實項目的構建。任何一項失敗，就停止遷移並保留原節點，不要直接刪除舊服務。

少量共享 Mac 的小型團隊

共享節點的隱性風險在於環境依賴。升級前先列出哪些工作流程依賴固定標籤、登入鑰匙圈、簽名憑證、本地快取、私有套件源或特定 Xcode 工具鏈。

較穩妥的順序是：

1. 新增或隔離一台節點，避免直接改動目前承擔發布工作的 Mac。
2. 複製必要工具鏈與服務帳戶，但限制其可接收的儲存庫或標籤。
3. 以低風險儲存庫驗證註冊、任務領取、測試與構建產物。
4. 將低風險工作流程逐步切換，再處理簽名、歸檔與發布流程。
5. 保存升級前後的任務日誌、Runner 版本、產物雜湊與回退演練記錄。

如果普通測試成功，但簽名或發布失敗，不能判定灰度完成。這種情況通常代表機器可執行程式，卻沒有完整恢復交付所需的鑰匙圈、權限或憑證狀態。

固定版本與受限網路：更新責任不能外包給在線狀態

關閉自動更新的節點，必須由團隊自行承擔版本生命週期。你需要明確指定負責人、維護窗口、安裝包來源和回滾保存位置，而不是等任務停止後才臨時處理。

檢查對象應包括：

• 代理、防火牆、DNS 與更新服務的連通性。
• 安裝包是否來自官方發布頁，校驗資訊是否已保存。
• Runner 服務帳戶是否有讀寫工作目錄及重新啟動服務的權限。
• macOS 服務設定、日誌位置與集中留存方式。
• 更新後是否仍能存取私有套件、憑證及內部 API。

官方文件要求你從 Runner 的監控與日誌判斷故障，不應只看控制台狀態；可依照監控與排解 Runner 問題的官方方法建立檢查項目。

受限網路環境尤其要設停止條件：安裝包無法核驗、服務帳戶權限不足、更新日誌不完整，或備用節點尚未通過真實構建時，都不要在生產節點上強行覆蓋。

企業節點池：用分批策略取代一次性切換

企業平台團隊應先生成一份節點清單，至少按 Runner 群組、CPU 架構、標籤、儲存庫權限、當前版本、更新方式及關鍵程度分類。這份清單的用途不是做資產展示，而是回答「哪一批節點可以先動、哪一批不能同時動」。

短生命周期節點、長期固定節點與自動擴縮節點，更新策略不能相同：

• 短生命周期節點： 建立新映像或新節點，通過驗收後淘汰舊節點，少在既有環境上原地修補。
• 長期節點： 先備份服務設定、簽名環境與快取依賴，再安排分批維護。
• 自動擴縮節點： 先更新節點模板，限制新節點流量，觀察註冊與任務領取後才擴大比例。

第一批應選非關鍵節點。觀察註冊、任務領取、失敗率、構建產物及發布鏈路後，才移動低風險儲存庫，最後才處理核心發布節點。任何批次出現版本不一致、任務持續排隊、簽名錯誤或重啟後服務未恢復，都應暫停下一批。

GitHub 的自託管 Runner 文件也提醒管理者注意標籤、群組、權限及節點維護；不要把所有節點放在同一個路由條件下，否則一台異常 Mac 可能讓排程判斷失去彈性。需要長期運作的環境，可先閱讀遠端 Mac 節點的服務常駐與管理入口，再把節點責任與工作流程權限分開設計。

FAQ：版本過期、升級與回退的現場判斷

怎樣查看自託管 Runner 當前版本？

在 Runner 管理頁面先記錄節點版本，再登入 Mac 查看服務目錄與啟動日誌。多節點環境可透過 API 盤點版本與狀態，最後以帳戶內即時下載指引和官方發布頁作為當日核對基準，不要引用快取頁面中的舊版本號。

關閉自動更新後，應怎樣升級 GitHub Actions Runner？

先測試更新服務連通性，確認代理、憑證、安裝包來源和服務帳戶權限。保存現有標籤及環境後，在隔離節點安裝並執行真實構建；只有註冊、路由、重啟和交付流程都通過，才可安排生產節點維護。

舊版 Runner 為何在線卻不接收任務？

在線狀態與版本資格是兩件事。最低版本限制可能在任務派送時拒絕舊節點，因此你要對照官方公告、節點版本和工作流程日誌。若日誌指出版本不符合要求，繼續等待不會恢復任務，應直接升級或切換備用節點。

Mac Runner 升級失敗，如何回滾？

先停止新任務並切換備用 Mac，保留升級前的 Runner 目錄、服務設定、標籤和簽名資料。恢復後重新確認節點註冊、標籤路由、重啟服務及真實 Xcode 構建；普通測試成功但發布失敗時，仍不可宣告回滾完成。

發布切換前的驗收評分

發布負責人最後要驗收的是「能否交付」，不是「畫面是否顯示在線」。你可以用下表評分：每個通過項目得一分；若簽名、歸檔或重啟恢復未通過，即使總分較高也應暫停切換。

現有 Mac 與隔離遠端 Mac：怎樣選擇下一步

如果現有 Mac 可以安排維護、能保存簽名環境，而且已有可用回退版本，繼續使用並按灰度流程升級通常最直接。相反，若它承擔唯一發布鏈路、無法停機、更新網路受限，或服務設定沒有可恢復副本，直接覆蓋生產節點會把版本風險、環境風險和交付風險疊在一起。

這時增加一台隔離的遠端 Mac，先複製最小工具鏈，再驗證註冊、標籤、簽名、真實項目與重啟恢復，通常比在唯一生產機上冒險更可控。你也可以先參考Mac CI 節點備份與重建方案所需考慮的環境持續性，再決定是重建節點還是暫時增加容量。

若你目前以單一本地 Mac 長期承擔任務，常見缺點是無法在升級時保持備援、硬體故障會直接中斷排程，並且簽名與快取環境往往只存在一台機器。若你改用一般雲端 Linux 主機，又會遇到 macOS 專屬工具鏈和 Apple 平台簽名流程不能直接替代的限制。對於需要短期保底、灰度測試或暫時擴充 Mac 構建節點的情況，租用 MacDate 的遠端 Mac，先建立隔離驗收環境再切換工作流程，會比直接改動唯一生產節點更穩妥；長期固定重負載或必須接駁特定實體設備的團隊，則應如實評估自購硬體。

下一步先盤點現有 Runner，並實際演練一次備用節點切換。若生產 Mac 無法安全停機，就在隔離的遠端 Mac 上複製最小構建鏈路，確認註冊、簽名與真實項目全部通過後，再從MacDate 的 Mac 節點方案安排短期容量或正式切換。