① 共享池目標與風險
共享遠端 Mac 池通常要兼顧 PR 回饋、可重現發版與公平取用；常見風險是資源互搶、簽章／鑰匙圈碰撞，以及「queued」卻分不清是標籤、容量還是鎖。
把自託管 Runner 當排程端點：須有人負責升級、Xcode 釘選與緊急排空；同機若有 VNC 使用者，衝突風險更高。
| 情境 | 建議 |
|---|---|
| 兩條產品線需要不同 Xcode／macOS 基線 | 分佇列：各自 Runner ＋ 標籤路由，避免 workflow 誤選工具鏈。 |
| 重度 CI 與 VNC 除錯常重疊 | 分佇列或分節點：CI 專用機或時段，避免人機互搶延遲。 |
| 發版 archive 需要容量保證 | 分佇列：release 類 workflow 只打到有專用 Runner 的標籤，不接 PR 雜訊。 |
| 僅單一 Xcode、併發低、衝突少 | 維持單一佇列：先量測再結構化，避免過早複雜化。 |
② 標籤路由對比矩陣
標籤路由決定哪台自託管 Runner 可接 job；命名混亂易誤路由或閒置硬體。生產 workflow 請用穩定、可機讀標籤。
| 路由型態 | 最適合 | 取捨 |
|---|---|---|
廣域池（macos、arm64） |
機隊同質、Xcode 單一釘選、追求利用率 | 難以為發版預留容量；任何 workflow 都可能吃掉 Runner。 |
工具鏈範圍（xcode-16-2、swift-6） |
儲存庫鎖定特定編譯器／SDK 行為 | Runner 與標籤需跟升級行事曆同步，維運成本較高。 |
SLA 分層（ci-pr、ci-release） |
PR 檢查與出貨構建分流 | 每一層背後都要有足夠硬體；空層會讓 job 永遠等不到 Runner。 |
租戶／小組切片（team-mobile、repo-core） |
計費分攤或嚴格爆炸半徑隔離 | 切片填不滿時利用率偏低；營運條目變多。 |
標籤命名規範（建議）
- 最低組合：
os＋arch＋xcode-<主版.次版>，例如macos、arm64、xcode-16-2。 - 可選角色後綴：
ci-pr、ci-release、experimental；勿在未遷移視窗下把同一角色標籤改指不同 Xcode。 - 保留 GitHub 預設如
self-hosted，並在內部 wiki 與儲存庫README維護唯一真實來源標籤表，供撰寫 workflow 的同事對照。
③ 排隊與鎖策略
併發排隊同時受 GitHub 語意、單機資源與簽章互斥約束；建議保守起步，有指標再放寬。
| 政策項目 | 建議起點 | 備註 |
|---|---|---|
| 併發上限（重度編譯／archive） | 同類 Mac 上 1 個活躍 job | 要在單機長期平行多個 archive，先加第二台節點再談。 |
| 併發上限（輕量檢查） | CPU 持續低於約 75% 且可用記憶體常態大於約 8 GB 時，可試 2 job | 搭配 workflow concurrency: 取消過期 PR 構建。 |
| 單池全局待處理深度 | 每池 pending 超過約 20 筆要熔斷或轉人工 | 避免靜默排隊數小時；應轉成告警與容量決策。 |
| 互斥／鎖 | 同一鑰匙圈路徑上，簽章或公證流程同時只跑一條 | 可用檔案鎖、Redis 或組織核准的 action，保證不可重入步驟序列化。 |
FIFO、配額與衝突場景可再對照共享資源池 FAQ。
④ 權限與隔離要點
⑤ 監控與告警
⑥ FAQ
標籤能取代真正的佇列產品嗎？
不能。標籤只是篩選器；當同時符合標籤的 job 多於 Runner，自然形成排隊。若需要跨儲存庫優先權、截止日或公平份額，請結合 concurrency 與外部協調，或將池拆到多台遠端 Mac。
一台機器應註冊幾個 Runner？
重度 iOS／macOS 構建通常每台一個 Runner 服務；多 Runner 若無嚴格上限，會同步放大磁碟與模擬器爭用。
什麼訊號代表該上多節點或團隊方案？
反覆 SLO 破表、簽章步驟常態衝突，或例行維護一次卡死所有儲存庫——這些屬於結構問題，靠微調標籤治標不治本，應增加節點或發版專機。
下一步：擴展多節點與團隊方案
單機標籤路由與併發排隊不足時，應拆 PR／發版池、按節點釘 Xcode。請至首頁比較多節點／團隊方案、購買頁（免登入）、幫助中心接入；進階見負載均衡、Runner 與租用成本。