工作流仍指定 macOS 14 Runner，退役通知已經出現，正式建置卻還沒切換？
最快解法：GitHub 公告指出，macOS 14 託管 Runner 映像預定於 2026 年 11 月 2 日退役；不要等到退役後才改標籤，先建立並行驗證工作流，再按真實建置、測試與發布結果決定切換。日期、受影響標籤與 brownout 安排以GitHub 官方退役公告為準。
仍使用 macOS 14 標籤的開發者：確認專案與新版 macOS、Xcode 工具鏈的相容性，安排低風險遷移。
CI 工程師：檢查工作流、依賴、快取與產物是否一致。
研發平台負責人：判斷託管 Runner 是否足夠，或是否需要可控的遠端 Mac 執行環境。
最後更新於 2026 年 10 月 7 日；退役資訊核實自 GitHub 官方公告，映像與軟體清單核對自官方 Runner 映像倉庫。發布前請再次確認公告日期、標籤與 brownout 安排是否變更。
收到退役通知後，先盤點受影響工作流
GitHub 公告列出的受影響標籤包括 macos-14、macos-14-large 與 macos-14-xlarge，這些標籤預定隨 macOS 14 映像於 2026 年 11 月 2 日退役。公告亦列有過渡期間的 brownout 安排；安排可能依官方更新調整，因此應直接核對退役公告中的日期與遷移建議，不要把一次成功執行視為延期保證。
盤點時，除了搜尋工作流中的 runs-on，也要找出透過自訂變數、共用工作流或動態矩陣指定 Runner 的位置。依序記下：
- 哪些分支、標籤或排程會觸發 iOS、macOS 的建置、測試和發布工作。
- 哪些工作共用相同的建置或部署工作流，改動 Runner 標籤會不會連帶影響其他專案。
- 哪些工作需要簽署、歸檔、真機測試或圖形工作階段；它們的驗收條件通常不只看編譯結果。
- 哪些正式工作流有替代標籤或回退方式，以及切換決策由誰批准。
將結果整理成一份遷移清單，並為每項工作指定負責人。這能避免只修改最顯眼的工作流，卻漏掉低頻發布分支或夜間排程。
切換前先建立可重現的基線
在修改標籤前，保存目前成功工作的設定與證據。基線不是為了證明舊環境一定比較好，而是讓團隊知道失敗究竟來自程式碼、工具鏈、依賴或工作流設定。
建議記錄 Xcode 與 SDK 的選用方式、部署目標、套件管理工具及依賴解析方式、環境變數、建置參數、測試目標、快取鍵和產物檢查方式。另保存有代表性的建置日誌、測試結果與歸檔產物資訊，並註明工作流觸發條件。工作流語法與 runs-on 設定可對照 GitHub Actions 工作流語法文件。
遷移時尤其要分開看待幾個常被混為一談的項目：Runner 標籤用來選擇執行環境；映像清單描述該環境的系統與工具；Xcode 版本決定實際使用的 Apple 開發工具；專案部署目標則由專案設定控制。更換標籤不代表這些項目會同步變更。
先用隔離工作流試跑候選標籤
不要直接將正式分支的 runs-on 全面替換。可先在獨立分支，或在不負責發布的並行 Job 中，以公告建議的候選 macOS 標籤執行同一套建置與測試。
候選標籤可能包括 macos-15 與 macos-26；實際使用前，應重新核對公告列出的建議標籤，以及macOS 15 映像清單和macOS 26 映像清單。不要只憑標籤推斷系統版本、架構或已安裝的 Xcode；映像軟體項目可能調整，應以官方清單當下內容確認。
試跑時至少確認：
- 工作流實際選到預期的 Runner 標籤，並記錄執行時可讀取的系統、架構與工具版本。
- 建置命令、測試選擇及產物路徑與基線一致，沒有因為測試被跳過而得到表面上的成功。
- 多個 Job 共用的環境變數、工作目錄或共用工作流，在新標籤下仍有正確設定。
- 試跑 Job 不會意外發布、覆寫正式產物或使用正式簽署流程。
這個階段的目標是收集可比較的證據，不是追求一次就通過。若專案有多種建置路徑，應分別試跑；不要拿一個輕量測試結果替代整條發布鏈路的驗證。
依失敗證據逐項修正工具鏈與快取
新 Runner 失敗時，先對照日誌與基線，把問題分類，再只調整有證據支持的部分。常見差異包括系統工具或工具版本改變、依賴解析結果不同、快取命中條件過寬、腳本假設固定路徑，以及建置腳本中的架構判斷。
若依賴快取造成可疑結果，先檢查快取鍵是否包含工具鏈、依賴鎖定檔或建置設定等相關條件，再做小範圍驗證。GitHub 的依賴快取文件說明快取的使用方式；遷移時不應在沒有證據下清空所有快取，因為這會同時增加下載與排查成本，也可能遮蔽真正的鍵值設計問題。
修正可按下列順序進行：
- 確認是工具不存在、版本不符，還是程式實際無法使用該工具。
- 比較鎖定檔、套件來源和安裝命令；只在依賴結果不同時處理解析條件。
- 檢查腳本是否依賴特定路徑、shell 預設值、環境變數或未明確宣告的工作目錄。
- 檢查快取鍵與還原條件，先用有針對性的鍵值調整驗證差異。
- 每次修正後重跑失敗步驟，再重跑受影響的整體工作流，保留前後紀錄。
如果團隊需要處理其他 Apple 工具鏈變更，也可參考本站的遠端 Mac CI 使用情境；但本次退役遷移仍須以 GitHub Runner 官方映像清單和專案自己的執行結果為準。
以真實建置、測試與交付結果驗收
在候選 Runner 上完成編譯，只能證明部分建置步驟可執行，不能直接推論發布鏈路已經遷移完成。請依專案實際使用範圍，分別驗證單元或整合測試、歸檔、簽署、產物檢查與交付步驟；真機或圖形工作階段需求，也要另行確認是否由目前的 Runner 方案承擔。
遷移驗收檢查清單
- [ ] 代表性的建置工作完成，且使用預期的系統映像、架構與 Xcode 工具鏈。
- [ ] 專案原本要求的測試有實際執行，測試目標與結果均已記錄。
- [ ] 歸檔與簽署步驟按專案既有發布鏈路驗證，沒有只以建置成功代替。
- [ ] 產物檢查方式一致，版本、內容和交付位置符合專案要求。
- [ ] 與基線的差異已有解釋；未解決的差異不會被誤判為無影響。
- [ ] 工作流負責人確認試跑證據，並清楚知道切換後的監看與回退條件。
在排查託管 Runner 與遠端 Mac 的責任邊界時，也要分辨「GitHub 託管執行環境」和「由團隊管理的自託管 Runner」：GitHub 的託管 Runner 文件與自託管 Runner 文件可供核對環境管理方式。若工作還依賴特定主機狀態、長時間常駐，或需要更細緻的主機控制，應把這些需求列為單獨驗收項目，不要預設一般託管 Job 可以取代。
通過準入條件後切換，並保留回退路徑
只有候選標籤通過專案要求的建置、測試與交付驗收，而且負責人確認試跑證據後，才切換正式工作流。切換前先約定監看項目、失敗時的停止條件及回退責任，再逐步更新使用舊標籤的工作，確認不再有必要的 macOS 14 引用後，才移除相應設定。
決策條件
- 若候選標籤已通過專案所需的建置、測試、簽署與產物驗收，且失敗時有明確的回退流程，則切換正式工作流；否則保留舊流程作為比較依據，暫緩擴大切換。
- 若差異可由受支援的映像、工具鏈或專案腳本調整解決，且團隊不需管理固定主機狀態，則先採用託管 Runner；若環境必須固定、需要長時間持續運行或需要更細的主機控制，則評估遠端 Mac CI。
- 若真機測試、圖形工作階段或特定硬體需求不在目前執行環境的能力範圍內，則把該環節獨立安排，不要將未完成的測試標示為整體遷移通過。
切換後保留基線、試跑紀錄與回退方式，直到正式工作流的關鍵任務完成驗收。若需要自主管理節點，還要把 Runner 註冊、權限、更新與故障處理納入維護工作；自託管環境不是只換一個標籤就能免除管理責任。
常見問題 FAQ
macOS 14 Runner 退役後，原本的工作流會自動改用新標籤嗎？
不要假設舊標籤會自動轉成新環境。應依工作流語法盤點每個 runs-on 指定，包含共用工作流與動態矩陣，再明確選擇候選標籤並試跑。官方公告中的退役與 brownout 安排可能更新，正式切換前要重新核對公告。
如何確認 macOS 15 或 macOS 26 Runner 實際提供的工具？
以官方映像倉庫的對應清單為準，核對作業系統、架構及所需工具，並在候選 Job 中記錄實際執行環境。標籤名稱本身不能證明某個 Xcode 或 SDK 已安裝，也不會改變專案的部署目標。若工具清單不符合需求，應先找出缺少項目，再判斷能否調整工作流或改用其他執行方式。
什麼情況適合由託管 Runner 轉向遠端 Mac CI？
當專案要求持續在線的建置節點、固定環境或更直接的主機控制，而託管映像無法滿足已驗證的工作流需求時，可進一步評估遠端 Mac。另一方面，若工作只是一般觸發式建置，託管 Runner 已能完成專案驗收，就不必為了退役通知而增加節點維護責任。可先檢視 RUVCLOUD 的方案資訊，再依實際需求比較。
macOS 14 退役讓團隊必須處理標籤與工具鏈變化，但不代表每個專案都要放棄託管 Runner。若新環境能通過真實交付驗收，維持託管方案通常更直接；若仍受限於環境固定、常駐執行或主機控制，託管 Runner 的映像週期、主機狀態控制範圍與環境維護責任便可能成為實際限制。這時可考慮租用 RUVCLOUD 的遠端 Mac，取得獨立的 macOS 執行環境，再依工作負載評估是否適合作為 CI 節點；若只是短期驗證或不需要固定主機，自行採用現有託管 Runner 仍可能更合適。