Runner Scale Set Client 可以用在 macOS 自託管 Runner 嗎？

可以，但它不是現成的 Mac 主機供應服務。GitHub 官方資料確認，這個 Client 可用於包含 macOS 的自訂 Runner 擴縮容方案；你仍須自行處理真實 Mac 節點的申請、啟動、環境初始化、JIT 註冊、任務後銷毀，以及失敗時的回收與重建。官方倉庫目前仍標示為 Public Preview，因此不宜直接視為穩定的生產成品。

GitHub Actions 的 Mac Runner 怎樣按佇列自動增加？

先由佇列或 Scale Set API 觸發擴容，再由你的平台建立可用的 Mac 節點，接著取得 JIT 設定並啟動 Runner。完成任務後，節點要自動註銷、清除或銷毀。若平台只能送出擴容訊號，卻沒有可核對的交付和回收紀錄，實際上仍是固定 Runner 池，而不是完整的彈性擴容。

Mac Runner 應該採用臨時節點還是長期在線節點？

普通開發建置可先用臨時 Runner 試點，藉此降低工作區殘留和任務串擾；簽名、發佈及涉及長期快取的工作則需要獨立節點池和更嚴格的清理驗證。長期在線 Runner 適合穩定、低變動的工作，但必須持續管理工作區、憑證和依賴殘留，不能只因註冊成功就視為安全。

沒有 Kubernetes 可以使用 Runner Scale Set 嗎？

可以。Runner Scale Set Client 的核心是編排 Scale Set API、擴縮容訊號與 JIT 設定，不等於必須使用 Kubernetes。沒有 Kubernetes 時，你可以用現有的硬體管理、虛擬化或遠端 Mac 交付流程承接節點生命週期；但若沒有自動申請、初始化與回收能力，應先採固定池加預熱節點的雙軌方案。

JIT Runner 怎樣處理 Xcode 快取和程式碼簽署？

JIT Runner 不會自動替你製作 Xcode 映像、還原 Simulator runtime、準備依賴或初始化簽署環境。快取要透過可重建的流程恢復，簽署憑證與金鑰則應放在受控的獨立節點池，並驗證任務完成後的清理。第一次全新建置、快取建置及節點重建後的建置，都應保留結果和日誌作為證據。

GitHub Actions Runner Scale Set Client：2026 Mac 擴縮容判斷

你現在看到佇列變長，卻不知道新增 Mac Runner 後是否真的能接單；最快解法是先確認節點能否自動交付、初始化、回收並把日誌帶出節點，再決定試點、雙軌或暫緩。

本週建議動作：先用一組可丟棄的遠端 Mac 節點跑非發佈工作流，依序記錄佇列等待、節點交付、Xcode 初始化、Runner 註冊與任務後回收；缺少其中任何一段，就先保留固定 Runner 池，採用預熱節點加人工擴容。

誰適合用這套判斷方法

這篇文章適合維護多個 GitHub Actions Mac Runner、希望按建置佇列動態增減節點的 DevOps 工程師。

如果你要隔離簽名任務，或正在比較固定遠端 Mac 節點、預熱池與按任務建立節點，下面的指標可以幫你把「能夠接單」和「可以進入生產」分開判斷。

最後更新於 2026 年 9 月 6 日；狀態與生命週期資料核實自 Runner Scale Set Client 官方倉庫、GitHub 自託管 Runner 文件及相關 API 文件。由於官方倉庫目前仍標示為 Public Preview，介面和支援狀態需要在正式擴大部署前重新複核。

先分清控制面與 Mac 節點供給

Runner Scale Set Client Mac 方案的第一個誤區，是把 Client 當成「按佇列自動建立 Mac」的完整產品。官方說明的範圍是編排 Scale Set API、接收擴縮容訊號，以及生成 JIT Runner 所需的執行設定；真實 Mac 節點由誰提供、如何開機、如何安裝工具鏈，仍由使用方負責。官方工作流程說明也沒有把主機供應、Xcode 映像製作或節點銷毀交給 Client。

你應先畫出一條可追蹤的交付鏈：

佇列出現需求後，平台是否能申請或挑選一台可用的 Mac。
節點啟動後，是否能自動套用 macOS、Xcode、依賴和必要權限。
Runner 是否取得短期設定並成功註冊，而不是只在控制台顯示建立成功。
任務失敗時，是否有回滾、隔離和重建紀錄。
任務結束後，節點是否註銷、清理或直接銷毀。

只要交付日誌中缺少節點識別、啟動結果、初始化結果或回收結果，就不能把它宣稱為彈性擴容。這時候比較穩妥的做法，是固定 Mac Runner 池搭配預熱節點，先以人工方式處理高峰。

六項指標如何把試點與生產分開

你可以把每次驗證拆成六個里程碑。每一項都要有可保存的紀錄，而不是只看工作流最後顯示成功。

節點供給：先驗證「拿得到 Mac」

Runner Scale Set Client 能發出需求，不代表你的 Mac 交付平台能在需要時提供合適節點。對 iOS 建置而言，節點至少要能進入正確的 macOS 使用者環境，並完成命令列工具、Xcode、依賴及權限初始化。

試點時不要只測健康檢查。應保存節點申請時間、實際可登入時間、初始化輸出和失敗回滾結果。若仍要人工複製磁碟、手動登入或逐台補環境，彈性擴容只是控制面上的訊號，還沒有形成可運作的供給能力。

生命週期：臨時 Runner 不等於自動隔離

長期在線 Runner 會保留工作區、依賴、快取與可能殘留的認證資料，優點是環境較快可用，代價是任務之間的邊界需要自行證明。單任務臨時 Runner 可以在任務後註銷或銷毀，較適合不可信輸入和需要清理的工作，但每次都要重建環境。

預熱臨時節點介於兩者之間：主機先準備好，但只在接單前取得短期 Runner 設定，完成任務後仍須清空或重建。GitHub 對臨時自託管 Runner 的建議，重點是避免任務完成後繼續接收工作；自託管 Runner 生命週期文件可作為驗收依據。

JIT 設定的保密邊界也要單獨檢查。設定由簽發到使用再到銷毀，不能寫入公開工作流輸出、長期日誌或共用工作區。官方的安全使用指引特別適合用來檢視公開倉庫、非可信拉取請求和簽名任務是否應分池。

冷啟動：把總耗時拆成四段

不要只用工作流總耗時判斷擴容是否成功。你的時間線應至少分為：

佇列等待：工作流已排隊，但尚未取得 Runner。
Mac 節點交付：從提出需求到主機可登入。
環境初始化：Xcode、Simulator runtime、依賴和快取恢復。
Runner 註冊：JIT 設定被使用，Runner 開始接收任務。

按需建立節點通常可以減少長期閒置，但會把交付和初始化成本放到第一個任務之前。純 JIT、保留最小預熱池和固定節點各有適用條件，不能使用沒有本站實測或權威來源支撐的通用秒數、並發量或節省比例作結論。

你應連續保留三種策略的實際紀錄，再按相同工作流比較。若高峰佇列反覆在節點完成初始化前超時，先增加預熱池；若節點長時間沒有工作，則檢查固定池是否比按需建立更難維護，而不是只看主機運行時間。

環境復現：註冊成功不代表能建置

一個空白 Mac Runner 可以成功註冊，仍可能在真正的 xcodebuild 階段失敗。原因可能是 Xcode 版本不同、Simulator runtime 未安裝、套件鎖定檔沒有恢復，或簽署環境沒有建立。

驗收應分成三個里程碑：

全新節點首次建置：證明初始化流程真的能準備完整工具鏈。
同一節點的快取建置：確認快取能加速而不攜帶不應共享的資料。
節點銷毀後重新建置：證明你依賴的是可重建流程，而不是某台主機的手動狀態。

把 Xcode 版本、SDK、Simulator runtime、依賴鎖定檔、快取來源和簽署資料分開記錄。Runner Scale Set 不會自動製作 macOS 映像，也不會替你建立圖形工作階段或程式碼簽署環境。若你正在整理自動重建 Xcode 建置環境的流程，應把每一項輸入都變成可檢查的初始化步驟。

權限與日誌：能接單不代表能上線

認證方案要從權限範圍、輪換責任和故障影響三方面比較。GitHub App 與個人存取權杖的管理方式不同；實際採用哪一種，應以所需的組織或儲存庫權限為邊界，不要把個人帳號權杖直接放進節點映像。

建立 JIT Runner 時，請使用占位符記錄設定，例如 <ORG_NAME>、<REPOSITORY_NAME>、<APP_ID>、<TOKEN> 和 <RUNNER_NAME>，避免把真實密鑰寫入教學、腳本或輸出。組織級 JIT 設定的請求與回應格式，應以官方 REST API 文件核對；接口參數變更時，再對照指定 API 版本的文件。

日誌不能只留在會被銷毀的 Mac 上。你需要驗證：

Runner 啟動、註冊、接單、完成和註銷紀錄是否轉存到節點外部。
節點銷毀後，仍能否依工作流識別失敗原因。
JIT 設定、權杖、簽署資料和工作區內容是否被遮罩或清理。
公開倉庫與非可信拉取請求，是否不能排入存有發佈憑證的節點池。

總成本：不要只比較建置執行時間

彈性方案的成本模型應包含 Mac 租用週期、預熱閒置、環境準備、失敗重建、外部日誌儲存及維護人力。若只比較工作流實際執行時間，很容易忽略平台團隊為處理初始化失敗、簽署問題和節點清理所付出的時間。

你可以把每週或每月的真實紀錄放入下列決策表。表內不預填價格或性能數字，因為租用週期、Mac 配置與交付方式必須以你的測試環境為準。

方案	供給與冷啟動	隔離與復現	維運負擔	適合的決策
固定 Runner 池	節點隨時在線，佇列波動時容量有限	需要持續清理工作區，環境較容易累積差異	主機長期管理與升級責任明確	任務穩定、節點需求少，先暫緩彈性化
最小預熱池加人工擴容	可吸收部分突發佇列，仍需人工補節點	可把預熱節點與簽名節點分開	同時維護固定節點和交付流程	自動化不完整但負載有波動，採雙軌
按任務建立臨時節點	閒置較少，但交付與初始化會進入首個任務等待	最適合單任務隔離，前提是能可靠重建	需要自動回收、外部日誌和失敗重建	已具備節點生命週期自動化，先小範圍試點

若你的團隊正估算Mac CI 節點的高峰並發需求，不要只用工作流數量推算節點數；還要把交付失敗、初始化重試、簽名任務獨立排程和日誌保留納入驗證。

FAQ：五個容易混淆的邊界

Runner Scale Set Client 可以管理 macOS 自託管 Runner 嗎？

可以，但它管理的是擴縮容控制流程，不是替你提供 Mac 主機。官方目前確認可用於包含 macOS 的自訂方案，但具體節點交付、初始化、註冊、回收和重建仍由你負責。由於官方倉庫仍屬 Public Preview，正式採用前應保留回退到固定 Runner 池的路徑。

GitHub Actions Mac Runner 怎樣按佇列自動擴容？

需要把佇列需求接到 Scale Set API，再由你的平台交付一台能執行 macOS 建置的節點，完成環境初始化後取得 JIT 設定。任務結束時還要註銷並清理節點。只有訊號、沒有節點交付日誌和回收證據，不能稱為完整自動擴容。

Mac Runner 應使用臨時節點還是長期在線節點？

開發建置可以先用臨時節點試點，簽名和發佈則應放在權限更窄、生命週期更嚴格的獨立池。長期在線節點適合穩定且低變動的任務，但你必須持續證明工作區、快取、憑證和依賴沒有跨任務殘留。

沒有 Kubernetes 能否使用 Runner Scale Set？

可以。你可以用現有的 Mac 租用、硬體管理或主機編排流程承接節點生命週期，並讓 Client 處理 Scale Set API 和 JIT 設定。如果目前只能人工建立 Mac，先採固定池加預熱節點的雙軌模式，比宣稱已完成自動擴容更準確。

JIT Runner 怎樣處理 Xcode 快取與程式碼簽署？

JIT Runner 只處理短期註冊設定，不會自動還原 Xcode 工具鏈、Simulator runtime、依賴或簽署環境。你應測試全新節點、快取建置和銷毀後重建三條路徑；簽署資料要放在獨立節點池，並確認任務後清理與外部日誌仍然成立。

用里程碑決定試點、雙軌或暫緩

在本週測試完成後，可依以下條件作決策：

已有自動交付能力：小範圍試點。你能自動取得 Mac、完成初始化、使用 JIT 設定、執行任務、轉存日誌並銷毀節點，先從非發佈工作流開始。
負載有波動但自動化不完整：雙軌。保留固定遠端 Mac Runner 池，另設預熱節點；高峰由人工擴容，等交付和回收證據完整後再增加按任務建立的比例。
任務穩定或節點很少：暫緩。若佇列波動不足以抵銷初始化、失敗重建和維護成本，固定池可能更容易追蹤，也更適合先改善環境復現。

這個判斷也要定期重做。官方倉庫由 Public Preview 轉為正式狀態、macOS 支援說明改變、認證接口變更，或 Runner 生命週期行為調整時，都應重新檢查既有腳本和回收流程。

從固定遠端 Mac 走向可驗證的彈性節點

如果你目前使用固定 Mac Runner，主要問題通常不是它不能建置，而是高峰時容量受限、閒置時仍要維護，並且長期在線工作區會增加清理與權限管理負擔。若改用只按任務建立節點，又可能面對冷啟動、Xcode 初始化失敗和日誌遺失；沒有完整交付平台時，這套方案未必比固定池更穩定。

較務實的路徑，是先在 VMSPIN 的遠端 Mac 方案中準備可獨立重建的測試節點，使用非發佈工作流驗證單任務回收、環境復現和日誌留存。當這些證據連續通過，再按你的佇列紀錄決定是否擴大租用節點池；若只是短期測試、版本驗證或臨時 CI 容量，租用遠端 Mac 通常比立即購買並長期維護一批實體主機更容易回退。