GitHub Actions macOS 14 Runner 退役前，怎麼查全遺留工作流？2026 清單

GitHub 官方公告：macOS 14 Runner 映像預定於 2026 年 11 月 2 日退役，受影響標籤包括 macos-14、macos-14-large 與 macos-14-xlarge。退役公告

症狀 → 只在預設分支搜尋 YAML，會漏掉複用工作流、動態標籤及沒有近期執行紀錄的任務。
最快解法 → 建立涵蓋組織、倉庫、設定來源和實際執行紀錄的清單，再按工作負載驗證替代標籤；單次文字搜尋不能作為全組織盤點完成的證明。

最後更新於 2026 年 10 月 8 日；退役日期、受影響標籤及 brownout 計畫核對自 GitHub 官方公告。

本文適合需要清查 GitHub Actions 組織依賴的管理員，以及負責 iOS/macOS CI 和建置基礎設施的平台工程負責人。
如果你要確認建置、測試或發布任務是否已驗收，也可以直接使用下文的工作流證據清單。

退役範圍要怎樣界定，才不會漏掉工作流？

退役公告列出三個受影響標籤：macos-14、macos-14-large 和 macos-14-xlarge。這是託管 Runner 映像的退役資訊，不應推論為使用自託管 Mac 的任務也會在同一日期停止運作。標籤清單、退役日期及公告中的替代建議，應以官方退役公告為準。

盤點時先界定「哪些東西在範圍內」，再開始搜尋。至少要記下組織內納入的倉庫、預設分支與仍受維護的工作流，並註明未檢查的倉庫、封存狀態不明的專案，以及因權限不足無法讀取的資料。把這些排除項目寫出來，才能區分「確認沒有依賴」與「目前無法確認」。

搜尋可從程式碼平台的程式碼搜尋、版本庫複製後的批次搜尋或內部索引開始；工具選擇不是盤點完整性的證明。尤其當倉庫分散在不同團隊、權限範圍或管理群組時，你需要一份倉庫母體清單作為分母，並逐項標出狀態，不能只列出搜尋結果。

設定來源完整度：從工作流一路追到標籤值

runs-on 的值可能直接寫在工作流檔案，也可能透過變數、矩陣或表達式產生。GitHub 的工作流語法文件說明工作流與工作項目的設定方式；Runner 選擇文件則說明如何指定執行工作的 Runner。盤點不能只搜尋一種字串寫法，而要沿設定資料流檢查實際值如何到達工作項目。

對複用工作流，請同時列出定義端和呼叫端。GitHub 的複用工作流文件可供核對工作流重用方式；若 Runner 值來自上下文或表達式，則需追查其取值來源及展開結果，可參考上下文文件與運算式文件。

為每筆命中保留倉庫路徑、工作流名稱、標籤來源和實際消費位置。如此一來，接手盤點的人能由清單回到設定源頭，判斷該改共用模板、呼叫參數，還是產生設定的程式，而不是在執行失敗後才追查誰覆寫了標籤。

執行紀錄可追溯性：靜態命中還要對照實際工作

文字掃描回答的是「設定中可能出現什麼」，執行紀錄回答的是「哪些工作流實際跑過」。兩者不能互相取代：某項任務沒有近期失敗，不代表它不使用舊 Runner；某個工作流檔案出現舊標籤，也不代表該分支或觸發方式已經跑過遷移測試。

如果組織使用 API 匯出執行資料，可參考 GitHub 的工作流執行 REST API 文件，再將紀錄與倉庫盤點表對照。你應記下工作流名稱、事件、Runner 標籤和最近可查結果；對沒有紀錄的工作流，標示「未驗證」，不要用「最近沒有失敗」代替結論。

特別留意只在特定分支或手動觸發的發布任務：日常 PR 流程沒有出錯，並不能證明這些低頻工作流已使用替代 Runner 完成驗收。

獨立 FAQ：標籤搜尋與全組織驗收

macOS 14 Runner 退役日期與標籤

GitHub 官方公告列明 macOS 14 Runner 映像的退役日期為 2026 年 11 月 2 日，受影響標籤為 macos-14、macos-14-large 及 macos-14-xlarge。官方退役公告亦列出退役前的 brownout 計畫及替代標籤建議。請在實際變更前重新核對公告，不要自行推測替代標籤或把託管 Runner 的公告套用到自託管 Mac。

找出所有使用 macos-14 的工作流

對每個納入範圍的倉庫搜尋 runs-on 及三個受影響標籤，並追查矩陣、表達式、輸入參數與產生器。之後把靜態命中和執行紀錄交叉比對，並列出未納入、未檢查或沒有足夠執行證據的倉庫。只有當每項命中都有來源、消費位置和處理狀態，搜尋結果才適合作為可複核的工作流盤點。

排查複用工作流中的 Runner 標籤

先找到共用工作流定義，再追到所有呼叫端，檢查 Runner 標籤是固定值、呼叫輸入，還是由矩陣或運算式帶入。清單必須同時保留源頭和消費位置，並逐一記錄修改後使用該共用工作流的任務是否完成測試。只修改共用工作流或只修改呼叫端，都可能留下另一側仍傳遞舊值的情況。

確認組織內倉庫都已覆蓋

建立完整倉庫母體，為每個倉庫標示已檢查、未檢查、例外或不適用，並記錄判斷依據。接著核對分支與觸發條件，確認工作流設定和實際執行紀錄一致；沒有執行證據的任務應列為待驗證，而不是算作已完成。最終清單需能從倉庫、工作流一路追到標籤來源、遷移差異和負責人。

Mac CI 遷移驗收：按工作負載分級並建立放行門檻

不能用「替代標籤已寫入檔案」作為遷移完成條件。一般 PR 驗證、定時回歸、簽署歸檔與正式發布的失敗影響不同，應分別記錄業務影響、負責人、工具鏈固定要求及未解相容性。對發布鏈路，至少要驗證專案實際需要的建置、測試、簽署和產物流程；對其他任務，也要依其真實觸發方式安排驗證。

替代 Runner 標籤應依官方公告核對，但官方建議不等於你的專案已驗收。遷移前後要保留工作流差異、實際執行結果和未通過項目；若工具鏈固定、相依套件或簽署步驟造成阻斷，記為具體風險，不要在沒有實測時推斷新標籤的效能、排隊狀況或費用。

可勾選的組織驗收清單：

• [ ] 建立組織內相關倉庫清單，記錄未檢查、無權限及封存狀態不明的項目。
• [ ] 檢查預設分支及仍維護的分支，記錄工作流名稱、觸發事件與檔案位置。
• [ ] 搜尋 macos-14、macos-14-large 和 macos-14-xlarge，並追查矩陣、表達式、複用工作流與產生設定。
• [ ] 為每項命中記錄設定源頭、消費位置，以及負責修改的團隊或人員。
• [ ] 對照實際執行紀錄；沒有執行證據、只接受手動觸發或只在低頻排程執行的工作，標為待驗證。
• [ ] 依公告核對替代標籤，並在真實專案流水線驗證建置、測試及需要的發布步驟。
• [ ] 保存變更差異、執行結果、未通過項目和已批准例外；每項未結案風險都要有負責人。
• [ ] 只有在範圍可說明、關鍵工作負載已驗證、例外有核准依據時，才將該項標記為已放行。

放行時，將未驗證項目、相容性阻斷和責任人視為明確門檻：完成驗證後遷移；無法立即完成時，保留經批准、具處理期限的臨時例外；若特定工作負載需要受控的 Mac 環境，則另外評估由自有 Mac 承載。不要把託管 Runner 的退役公告寫成自託管 Mac 的退役狀態，也不要只因替代標籤能啟動工作，就判定發布鏈路已通過。

如果你目前依賴託管 Runner，變更標籤的工作量之外，仍需處理平台映像更新節奏與特定工作負載的驗收；自行維護 Mac 則能讓你掌握主機環境，但也要承擔硬體、維護和故障處理。若某些已驗證的 CI 工作需要獨立 Mac 環境，先閱讀 KVMFLUX 的 Mac CI 使用情境，再按團隊使用週期核對方案與計費週期。若工作負載需要實體介面或長期固定、高負載執行，自有設備可能更合適；若你要臨時承接建置或測試任務，則可把遠端 Mac 納入候選，並先用清單中的真實流水線完成驗收。

延伸閱讀

• 盤點自託管 macOS Runner：部署、標籤路由與安全驗收
• 了解 GitHub Actions macOS Runner 自動擴容的企業部署與回收流程

常見問題 FAQ