時間線｜截至 2026 年 10 月 15 日，GitHub 已公布 macOS-14 Runner 的 Brownout 時段，並確認於 2026 年 11 月 2 日退役；日期與 Runner 標籤以官方退役公告為準。這週先核對失敗時間及
runs-on實際標籤，再按發布風險切換到已驗收的替代環境；未能及時驗證的關鍵發布，使用團隊已驗收的備用 Mac 路徑，不要先改應用程式碼。最後更新於 2026 年 10 月 15 日；Brownout 時段、退役日期與標籤核實自 GitHub 官方公告及托管 Runner 文件。
負責企業 GitHub Actions 工作流程的 IT 管理員，可用本文找出仍路由到 macOS-14 的關鍵工作。
負責 iOS/macOS 發布的工程師，可用本文分辨 Runner 標籤、映像差異與專案故障。
管理 Mac CI 容量的技術負責人，可據此判定備用執行路徑是否有足夠驗收證據。
SECTION 01 GitHub Actions macOS-14 Brownout 失敗排查：先界定故障邊界
Brownout 期間出現失敗，不等於每個 CI 問題都由 Brownout 引起。你要先把失敗時間、工作流程、分支及實際 Runner 標籤對上官方公告；只有時間與標籤都吻合，才把該工作列為優先調查對象。
GitHub 公告確認 macOS-14、macOS-14-large 與 macOS-14-xlarge 的 Brownout 時段及退役日期，但各次 Brownout 的具體時段應直接查公告，並依公告時區換算。不要憑排程時間推測：查看工作流程執行紀錄中的工作開始時間、完成時間與 Runner 標籤，保存失敗連結及提交版本，供後續對照。
| 失敗線索 | 需要核對的證據 | 下一步處置 |
|---|---|---|
| 失敗落在公告的 Brownout 時段，標籤為 macOS-14 系列 | 執行時間、工作流程名稱、實際 Runner 標籤與失敗步驟 | 列為 macOS-14 相關候選，先確認是否阻斷簽章或正式發布 |
| 失敗時間吻合，但標籤不是 macOS-14 系列 | Runner 標籤、工作流程版本、分支與重用工作流程來源 | 不直接歸因 Brownout；依錯誤步驟排查其他映像或專案問題 |
| 標籤是 macOS-14 系列，但失敗不在公告時段 | 執行時間及工作流程近期變更 | 保留標籤依賴風險，同時按一般 CI 故障調查 |
| 時間和標籤都不吻合 | 工作流程日誌、相依服務狀態、提交差異 | 排除 Brownout 為已證實根因，避免未經驗證地全域改標籤 |
SECTION 02 工作仍落在舊 Runner 時，從生效設定查起
只在某一個 YAML 檔案搜尋並替換標籤，不能證明遷移已生效。工作可能由其他工作流程、特定分支或重用工作流程呼叫；你需要從失敗的執行紀錄回溯實際採用的設定。
先打開失敗工作的執行頁面，記下顯示的 Runner 標籤，再依序檢查該次執行所用的工作流程檔案、分支，以及有沒有呼叫重用工作流程。GitHub 的依標籤選擇工作 Runner 文件說明工作如何依 runs-on 標籤選擇執行環境；若設定集中於共用工作流程，亦須追查重用工作流程的設定方式。
檢查時要注意幾種常見落差：改的是沒有被呼叫的檔案；只更新預設分支，實際執行來自尚未更新的分支；或只改了部分工作，歸檔與簽章工作仍留在舊標籤。遷移記錄應連同實際執行頁面保存，而非只有一份已修改的 YAML。
SECTION 03 替代映像不能只看標籤：用專案需求作選擇
macOS-15 與 macOS-26 都不能只因為標籤可用，就當成 macOS-14 的等效替代。版本差異可能改變 Xcode、SDK、工具鏈或相依套件的行為；要以專案實際需求和同一提交的驗收結果選擇。
| 選項 | 你應核對的環境資訊 | 適合的決策條件 | 尚未通過時的處置 |
|---|---|---|---|
| GitHub Actions macOS-15 Runner | Xcode、SDK、預裝工具與架構；對照macOS-15 映像清單 | 專案需求與映像內的工具相符，且同一提交通過完整發布驗收 | 保留未通過項目，勿把標籤已更換視為遷移完成 |
| GitHub Actions macOS-26 Runner | 逐項核對 Xcode、SDK、工具與架構；參照macOS-26 映像清單 | 專案已能在該映像完成建置、測試及簽章，並有回退依據 | 先在隔離工作流程驗證，不要直接讓正式發布依賴未驗收映像 |
| 團隊已驗收的備用 Mac | 權限、憑證交接、產物保存與稽核紀錄是否已實測 | 遠端托管映像尚未通過，而發布路徑已在此 Mac 驗證 | 沒有實際流水線測試證據，就不可假設能無縫接替 |
官方文件可用來核對 Runner 的標籤與環境資訊，但不能替你的專案作相容性保證。GitHub 的托管 Runner 參考文件及Runner 環境說明可協助確認平台提供的環境邊界；最終選擇仍要依同一提交的實際建置和發布結果。
SECTION 04 按發布風險縮小範圍，再逐項完成驗收
不要把所有工作一次改到新標籤。先把失敗工作分為 PR 驗證、模擬器測試、歸檔簽章及正式發布，確認哪一段正在阻斷交付，再按以下步驟處理：
- 固定故障樣本。 保存失敗的執行連結、提交、分支、工作流程名稱、開始時間及錯誤日誌；依官方公告時段和時區確認是否吻合。
- 確認實際 Runner。 從執行紀錄查看標籤，並追查工作流程中實際生效的
runs-on、分支版本與重用工作流程來源。 - 辨識受影響的發布環節。 區分日常 PR 檢查與正式簽章、歸檔或發布工作；先恢復會阻斷正式交付的關鍵路徑。
- 以同一提交試跑替代映像。 分別記錄 macOS、Xcode、SDK、依賴工具與架構，執行建置和測試。不要以「改標籤後成功排程」替代環境驗收。
- 完成發布驗證。 確認歸檔、簽章、產物完整性及下游交付都通過；簽章或發佈步驟未測過，就不能把該映像列為正式發布環境。
- 寫明放行與回退條件。 記錄未解的相容性問題、負責人、適用工作及回退方式；完成驗收後才逐步擴大工作範圍。
注意： 只要簽章、憑證取得或產物交接尚未在替代環境實際跑通，就不要用模擬器測試成功推論正式發布也安全。先隔離非關鍵工作驗證，避免全域更換標籤擴大影響。
如果你管理的是自託管執行節點，還要另外核對節點維護與工作分派方式；GitHub 自託管 Runner 文件可供確認官方管理邊界。自託管節點或備用 Mac 是否適合承接發布工作，仍取決於你們對程式碼、憑證、產物及稽核紀錄的實際交接驗證。
SECTION 05 退役前的放行里程碑：保留可證明的回退路徑
依 GitHub 官方公告，macOS-14、macOS-14-large 與 macOS-14-xlarge 的退役日期為 2026 年 11 月 2 日。這是已公布的日期；請勿把它與 Brownout 時段混為一談，也不要從公告之外推測每次工作失敗的原因。
在退役前，把遷移狀態分成三種：尚未開始、替代映像正在驗收、關鍵發布已完成驗收。只有最後一種狀態，且留有實際工作流程結果、產物核驗紀錄、回退條件與責任人，才適合放行正式發布。尚未完成驗收的工作，應限制影響範圍並安排明確的補測，而非只更新標籤後視為結案。
如果團隊需要可控的 macOS 執行環境，遠端 Mac 可以納入備用承載方案，但不可在沒有驗收證據時承諾它已能替代托管 Runner。你可先查看 VPSNIX 的服務說明與支援資訊，確認存取與環境條件，再依自己的工作流程驗收；如需評估按期租用成本，可參考VPSNIX 方案資訊。若團隊已有通過真實發布測試的 Mac 執行路徑，才把它列為應急選項；若工作負載長期穩定且需要完整自主管理，也應一併比較自購設備與自行維護的成本，不必為了 Brownout 倉促改變長期架構。
SECTION 06 常見問題
CI 在 Brownout 時段失敗，就能確定是退役造成嗎？
不能。時間吻合只能提供線索，還要確認失敗工作實際採用 macOS-14 系列標籤，並檢視錯誤發生的位置。若標籤或時間不吻合，應按一般環境或程式問題排查，避免把不相關故障一併歸因於 Brownout。
macOS-14 工作流應該遷到 macOS-15 還是 macOS-26？
以你專案能通過完整驗收的環境為準，而不是按版本號選擇。對照官方映像清單及專案所需工具，使用同一提交完成建置、測試、簽章與產物核驗；若替代映像仍有未解問題，暫以已驗收的備用路徑保護關鍵發布。
Runner 標籤更新後，如何確保修改確實生效？
檢查實際失敗執行所用的分支和工作流程，從執行紀錄確認 Runner 標籤，再追查是否由重用工作流程提供設定。只改一份沒有被呼叫的檔案，或只改預設分支，都不能證明實際發布工作已完成遷移。
備用 Mac 尚未跑過正式發布，可以先作緊急替代嗎？
不能只憑設備可連線就當成可用備援。至少要驗證程式碼取得、憑證權限、建置測試、簽章、產物保存及稽核交接；若這些環節未跑通，應明確標記為未驗收路徑，不能把它當成已證實可接替托管 Runner 的方案。
SECTION 07 常見問題 FAQ
Brownout 期間的 CI 失敗，怎樣判斷是否與 macOS-14 有關？
先將失敗時間換算到公告採用的時區，對照官方 Brownout 時段，再從該次執行紀錄確認實際 Runner 標籤。若兩項都吻合，將它列為 macOS-14 相關候選；仍需查看失敗步驟與同提交重跑結果，不要只憑時間判定根因。
GitHub Actions macOS-14 Runner 會在何時退役？
GitHub 公告列出的 macOS-14、macOS-14-large 與 macOS-14-xlarge 退役日期是 2026 年 11 月 2 日。Brownout 的各個時段應以公告原文為準，並留意時區；如果工作流仍依賴這些標籤，應在退役前完成遷移驗收，而非等到排程失敗才處理。
macOS-14 工作流改用 macOS-15 還是 macOS-26 比較合適？
不要只按版本新舊決定。先核對專案所需的 Xcode、SDK、相依工具與架構，再用同一提交測試建置、測試、簽章和產物；選擇能完整通過專案驗收的映像。若兩者都有未解問題，先保留已驗收的備用執行路徑。
切換 macOS Runner 後，iOS 發布流水線要驗證哪些環節？
用同一提交跑過相依安裝、建置、測試、歸檔、簽章及產物核驗，並確認憑證取得方式與發布權限仍符合團隊規範。保存工作流程與執行紀錄，記下未解的相容性差異、負責人和回退條件；只有關鍵路徑也通過，才放行正式發布。