GitHub Actions 自架 Runner 排隊不執行？先做版本更新檢查
自架 GitHub Actions Runner 的 workflow 若突然一直排隊，第一個要看的不只是 workflow YAML，而是 runner 版本。GitHub 已公告恢復最低版本要求的強制時程；在強制日之前，舊版 runner 會先遇到不能註冊或不能執行 job 的窗口，完整強制則依 GitHub.com、Enterprise Cloud 與資料落地環境有不同日期。
2026-07-25 更新：GitHub Enterprise Cloud with Data Residency 的最後一輪 brownout 已在 7 月 20、22、24 日發生，完整強制預計從 7 月 31 日開始。若你的工作流曾在這些日期短暫卡住，先盤點 runner version 和 image 發版流程，再判斷是否另有 label 或容量問題；不要只靠重新執行 job 掩蓋版本落後。
最實際的處理方式是：先確認 job 被派到哪一組 runner，再比對該主機或容器 image 的 runner 版本與 actions/runner release。
先分辨是「沒有 runner」還是「runner 太舊」
在 repository 的 Actions 頁面打開卡住的 job，先看它要求的 labels；再到 organization 或 repository 的 Settings → Actions → Runners 確認對應 runner 是否 online、idle，以及最後活動時間。若是 autoscaling 或 ephemeral runner，也要檢查 controller 是否確實建立新 pod／VM。
常見現象不只一種：
| 現象 | 優先檢查 |
|---|---|
| job 一直等待符合 label 的 runner | label、runner online 狀態、autoscaler 容量 |
| runner 能看見但不接 job | runner 軟體版本與 GitHub 的最低版本要求 |
| container 每次啟動都更新很久 | image 內版本、是否使用 ephemeral runner、更新策略 |
| 手動停用更新後突然停止排程 | 是否超過 GitHub 要求的更新期限或有安全更新 |
不要只靠自動更新
一般 self-hosted runner 預設會在有新版本時更新。但 Docker、Kubernetes 與 ephemeral runner 常刻意使用 --disableupdate，避免每次新容器都下載更新；這是合理的部署設計，但更新責任就移到 image 的維護流程。
GitHub 文件指出，停用自動更新後仍必須定期更新；新版本發布後超過 30 天，服務可能不再把 job 排給該 runner。遇到 critical security update 時，更新前也可能停止排程。因此「image 可以穩定重建」不等於「版本可以一直固定」。
可回復的更新流程
- 記錄現況：保留目前 runner image tag、runner group、labels 與最近成功 job。
- 更新測試 runner：先替非正式 repository 或獨立 runner group 更新 runner binary／image。
- 跑代表性 workflow：至少包含 checkout、cache、需要的 container 或部署權限。
- 逐批替換：讓舊 runner drain，不接新 job 後再替換；不要在一個唯一 runner group 上直接全數停機。
- 確認 GitHub UI：確認新 runner 成為 online，並實際完成一個 job，不只看主機上的 process 存活。
如果使用 Actions Runner Controller（ARC），更新通常應透過 controller 與 runner image 的既定發版方式完成，而不是進入單一 pod 手動改 binary。這樣下次 autoscaling 才不會又生出舊版 runner。
把版本檢查放進日常維運
最小化做法是訂閱 actions/runner releases，並把 runner image tag 或版本列入每月維護項目。對 --disableupdate 的 runner，可在 CI 或監控中記錄目前版本，讓「job 排不動」不會成為第一次知道版本落後的時機。
官方時程會更新；本文發布日（2026-07-21）應以公告頁的環境對照表為準。不要把某一個日期複製進內部 runbook 後就忘記回看來源。
強制日前，用 API 做一次版本盤點
GitHub 的 self-hosted runner REST API 回傳每台 runner 的 version、status、busy、ephemeral 與 labels。這比從個別 VM 登入檢查更適合先找出整批舊 image；呼叫 organization endpoint 需要有讀取 self-hosted runners 的適當權限。
gh api --paginate '/orgs/ORG/actions/runners?per_page=100' \ --jq '.runners[] | [.name, .version, .status, .ephemeral, ([.labels[].name] | join(","))] | @tsv'輸出後至少分成三群：可自動更新的常駐 runner、由 image 建立的 ephemeral runner，以及 offline 或不再使用但仍註冊的 runner。2.329.0 是重新註冊的最低門檻，不是可以永久停留的執行版本；即使剛好高於它，仍要在新 release 後 30 天內更新。
如果是 Enterprise Cloud 或 Enterprise Cloud with Data Residency，也可從 audit log 的 runner registration events 看登錄時的版本。這能補強「哪些 runner 正在重新註冊」的觀察，但 GitHub 明確說它不是所有已連線 runner 的完整 inventory，因此不能取代 API 清單。
一次盤點後要留下什麼
- runner group、labels、image tag 與實際 runner version 的對照表；
- 每個 ephemeral image 最後重建時間與負責更新的 pipeline；
- 測試 runner group 完成 checkout、cache、部署等代表性 workflow 的紀錄；
- 下一個 runner release 的檢查日期，而不是只記下這次升級日期。
有了這份基線，之後若 GitHub job 再排隊，就能很快區分「版本強制」和「容量、label、網路」三種不同問題。
常見問題
Q: 把 --disableupdate 拿掉就能解決所有問題嗎？
A: 不一定。它能讓常駐 runner 自行取得更新，但 ephemeral 容器仍需要正確的 image 與 autoscaling 設定。先確認你是由誰建立 runner，再決定由 runner 本身或 image 發版流程負責更新。
Q: 可以等 job 真的卡住再更新嗎？
A: 不建議。最低版本要求與 critical update 可能讓 GitHub 停止排程；等到正式工作流卡住才處理，通常沒有測試環境與回復空間。固定週期測試新版本更安全。
參考資料：
GitHub Changelog：自架 Runner 最低版本要求時程
回報錯字、失效連結，或告訴我你想看的延伸主題。