GitHub 強制執行自架 Runner 最低版本：代理 CI 上線前檢查
GitHub Enterprise Cloud 計畫於 2026 年 9 月 25 日開始全面執行自架 Actions runner 最低版本要求。GitHub 表示，當某個更新已發布超過 30 天，仍未升級的 runner 可能失去註冊或執行支援；若發布重大安全更新，工作排隊也可能暫停，直到 runner 完成升級。
對代理工程、瀏覽器自動化、已授權資料收集和區域驗證團隊而言，真正風險是錯誤歸因。過舊 runner 可能無法註冊、持續排隊或無法執行，但監控卻將它記成「代理測試失敗」。實際上，請求可能根本沒有抵達代理閘道。
本次執行改變了什麼
此時間表面向使用 GitHub Enterprise Cloud 的自架 runner，包括 GitHub 公布的雲端執行安排。此特定時間表不包含 GitHub Enterprise Server。
GitHub 將兩個邊界分開：
- 註冊支援：runner 能否註冊或重新註冊；
- 執行支援：已連線 runner 能否接收並執行工作。
執行生效後，舊 runner 可能在任一邊界失敗。必須分別記錄排隊、註冊和網路測試執行狀態。只有 runner 接收工作且網路測試輸出明確啟動標記後，才應開始統計代理健康指標。
建立完整 runner 清單
不要只看某個儲存庫中顯示「在線」的 runner。應涵蓋組織、企業、自動擴充、臨時 runner，以及未來可建立 runner 的映像與範本。
至少記錄：
runner_group
runner_name_or_instance_id
runner_version
operating_system_and_architecture
image_or_template_digest
registration_source
last_registration_time
last_job_time
labels
network_zone
proxy_test_role
owner
upgrade_method檢查安裝腳本、黃金映像、容器映像、機器範本和災難復原副本。只升級正在執行的機器並不足夠，因為自動擴充器可能在五分鐘後重新建立舊版本。
分離 runner 健康與代理健康
加入明確的生命週期標記：
- 工作流程進入佇列；
- runner 被分配；
- 工作啟動；
- 代理測試程序啟動；
- 抵達代理閘道；
- 驗證完成；
- 目標斷言完成；
- 清理完成。
只有第 5 至第 7 階段描述代理路徑。持續排隊的工作不應降低代理成功率、觸發出口輪替或建立供應商事故。
應為 runner 不受支援、註冊被拒、工作未分配、工具啟動失敗和真實網路故障分別建立錯誤類別，避免污染採購與可靠性資料。
在截止日前找出舊版本
GitHub 提供 runner 版本資訊和稽核證據，包括註冊事件。可以使用適用於儲存庫、組織或企業的檢視，但要注意：註冊記錄只顯示發生過註冊的 runner，未必是全部線上或休眠機器的完整清單。
交叉比較三類來源：
- 控制平面中的已註冊 runner 清單；
- 基礎設施清單與自動擴充範本；
- 最近工作流程實際執行時記錄的 runner 版本。
近期沒有執行工作的 runner 仍可能在容錯移轉時被選中，因此備用池與災備池亦須獨立測試。
升級「生產機器的工廠」
先更新建立 runner 的機制：
- 安裝與啟動腳本；
- VM、容器和機器映像；
- 自動擴充啟動範本；
- 離線快取的軟體套件；
- runner 更新所需的網路允許清單；
- 決定 runner 何時加入標籤群組的健康檢查。
然後替換或升級既有執行個體。新 runner 必須先回報受支援版本，再接收敏感代理憑證或正式網路工作。
不要為了完成升級永久擴大出站存取。應使用核准的成品來源，依組織流程驗證簽章或摘要，並縮小代理繞過規則。NO_PROXY 政策測試可證明升級流量與測試流量均走在預期路徑。
升級後執行代理 CI 金絲雀
在許多叢集中，runner 升級同時會改變基礎映像、憑證、shell 工具、瀏覽器、程式庫或服務設定。全面替換前必須執行低流量金絲雀。
至少測試：
- runner 註冊與工作領取；
- Action 啟動及所需執行環境；
- 代理密鑰注入且記錄不洩漏；
- 代理閘道和目標網域的 DNS 行為；
- 實際使用的 HTTP 代理、HTTPS CONNECT 與 SOCKS；
- 已購買的 IPv4 與 IPv6；
- 憑證與主機名稱驗證；
- 黏性和輪替工作階段語義；
- 回應完整性、取消和有界重試；
- 成品上傳與清理。
只對自有或明確授權的目標執行。比較舊 runner 與升級 runner 時，保持代理帳號、目標、負載和通過條件不變。
Node 24 Actions 遷移方案可協助區分 JavaScript Action 執行環境、應用程式執行環境與代理行為。
替換期間保護憑證
臨時 runner 應在通過版本與安全狀態檢查後，才接收短期、最小權限憑證。不能將代理密碼、Cookie 或 Token 固化進機器映像。
下線舊執行個體時：
- 停止分配新工作；
- 等待進行中工作結束，或安全取消；
- 撤銷 runner 註冊材料；
- 刪除臨時代理允許清單；
- 依政策清除本機工作目錄與診斷成品；
- 確認執行個體不能從舊快照重新加入。
若除錯記錄洩漏代理憑證，應立即輪替。刪除 runner 並不會讓外洩密鑰失效。
設計仍受支援的回復
回復不能還原至已不受支援的 runner 版本。應保留 runner 仍在支援窗口內的舊基礎設施版本，或保留少量目前版本的已驗證備用池。
建議推進順序：
- 一台非正式環境 runner；
- 每個網路區域一台正式金絲雀；
- 每個標籤群組的 10%；
- 一半叢集；
- 證據穩定後全面替換。
每個階段比較工作領取延遲、有效結果率、p95 測試耗時、重試放大及每次有效結果成本。若回應驗證下降，僅佇列更快不代表成功。
工作停止時的正確排查順序
若執行日前後工作持續排隊：
- 檢查 runner 分配和版本註解；
- 確認 runner 可以註冊，且符合所需標籤；
- 查看 runner 服務記錄中的更新或相容性錯誤；
- 檢查自動擴充器是否正在啟動舊範本；
- 只有網路測試實際啟動後，才調查代理 DNS、驗證、通道和出口。
不要透過輪替住宅 IP、擴大並行或更換代理供應商來修復根本沒有執行的工作。這些動作只會增加成本並破壞診斷證據。
就緒檢查清單
- 已盤點全部 runner 群組、備用池和自動擴充範本。
- 最新建立的 runner 回報預期的受支援版本。
- 分別監控註冊支援與執行支援。
- 佇列失敗不會污染代理成功率。
- runner 工廠映像與啟動腳本已更新。
- 離線快取無法重新建立舊 runner。
- 升級流量遵循核准的網路政策。
- 代理憑證在狀態檢查後注入，且從不固化進映像。
- 金絲雀涵蓋 DNS、驗證、通道、TLS、路線與回應完整性。
- 分別測試 IPv4、IPv6 與必要市場。
- 取消、清理與成品處理均通過。
- 回復使用受支援的已驗證 runner 版本。
- 已下線 runner 無法重新加入，註冊材料已撤銷。
常見問題
本次執行適用於 GitHub Enterprise Server 嗎？
GitHub 公布的 9 月 25 日時間表適用於 GitHub Enterprise Cloud。公告說明 GitHub Enterprise Server 不受此特定變更影響。
安裝超過 30 天的 runner 會同時停止嗎？
規則與更新可用時間以及註冊和執行要求的最低版本有關。應查看目前註解及 API，而非僅憑安裝日期推斷資格。
runner 顯示在線便一定合規嗎？
不一定。在線狀態不能證明後續註冊或執行資格，自動擴充器也可能繼續建立舊版本。必須驗證實際執行版本和來源映像。
是否應改用 GitHub 託管 runner？
這取決於網路存取、資料處理、區域要求和安全政策。託管 runner 可作為暫時診斷對照，但不能取代正式 runner 架構驗證。
上線期間最重要的指標是什麼？
按 runner 版本與網路區域拆分的有效結果率。佇列延遲、執行故障和代理路徑故障必須分別統計。
合規說明
只對自有或明確獲准的系統、帳號、資料與市場執行代理和資料收集檢查。遵守存取控制、隱私要求、目標條款與速率限制。保護 runner 與代理憑證，只保留必要證據，不得使用代理輪替隱藏違規行為。
來源說明：GitHub，《GitHub Actions: Minimum version enforcement timeline for self-hosted runners》，2026 年 6 月 12 日；2026 年 9 月 24 日複核時間表。外部研究位置僅保存在內部營運記錄中。
