shell、docker 與 SSH executor 以及 Jenkins inbound 與 SSH Agent 的責任邊界；接著給出可複製標籤與 resource_group 語意、六步從裸機到可灰階池、以及三條可進季報的觀測口徑；並與站內 GitHub Actions 自建 Runner、多區 RTT 與租期、多人共用節點治理 交叉閱讀，避免同一預算被三套編排器各算一半。2026 年 GitLab Runner 與 Jenkins macOS Agent：五條把「能跑」當成「能規模化」之前的誤判
GitLab Runner 在 macOS 上最常見的落地形態仍是 shell executor：它讓您最快看到綠色流水線，卻也把鑰匙圈視窗、互動式登入工作階段與無人值守批次綁在同一使用者網域裡。Jenkins 側若用 inbound 代理把控制連線回連到控制器，又未把節點標籤與 SCM 區域寫清，就會出現「控制器在美東、倉儲庫在新加坡、執行器在香港」這類邏輯可通、實體很慢的組合。獨佔雲端 Mac 的價值在於把執行器變成可命名、可凍結映像、可稽核出口的長期資產；若仍按「誰喊得響就給誰加標籤」臨時擴容，只是把排隊雜訊從 SaaS 佇列搬到自家標籤池裡。
當您在新加坡、東京、首爾、香港與美東美西之間分配開發者與外包 QA 時，若私有成品倉、容器登錄服務與 Git LFS 仍落在單一地理域，而 Runner 或 Agent 卻按人力就近隨手掛到另一域，解析階段與成品搬運會吃掉大量牆鐘時間，此時再堆核心數只會複製誤解。應先回到 多地區選區與租期 把資料面與執行器同洲寫進合約，再對照 GitHub Actions Runner 裡關於組織級快取與佇列群的敘述，決定「哪條鏈路留在 GitHub、哪條必須落在 GitLab 或 Jenkins」。
另一條常被低估的線是人機混用：白天有人用遠端桌面改 Xcode 路徑、夜裡批次仍讀同一個 login 鑰匙圈，表現為「偶發紅」實則是競態。若團隊已閱讀 多人共用節點治理，應把 SSH 席位、CI 佇列與 Runner 標籤三套命名寫進同一變更單，否則除錯時會出現「日誌說是簽章失敗、現場卻有人在跑互動式 xcodebuild」的雙真相源。
最後，不要把「GitLab 自帶 SaaS Runner 分鐘數」與「獨佔裸金屬按月租」依 CPU 紙面核心數直接比價：前者隱含映像輪換與修補勞動，後者隱含漂移治理與簽章材料輪換；二者與 Xcode Cloud 混搭 的蘋果託管路徑混在同一預算科目裡，極易 double count 並行度。下面五條把禁止條前置成清單，逐條排除後再進入第二節的分叉表。
把 shell executor 成唯一真相：適合快速驗證，但長期承載多團隊時應評估 docker 或 SSH 隔離邊界，否則全域 npm 前置詞會成為共享可變狀態。
同一臺雲端 Mac 同時註冊 GitLab Runner 與 Jenkins Agent 卻不拆標籤池：兩套編排器會爭用磁碟 inode、Xcode 選擇與 launchd 槽位，除錯時日誌互相覆寫。
忽略 GitLab resource_group 與 Jenkins throttle 語意：平行矩陣在離峰也會寫爆磁碟，財務看到的是「又買了一臺」而不是「佇列擁有者缺失」。
把控制器與執行器的 TLS 往返當成零成本：跨洲 inbound 連線在晚高峰會放大尾延遲，應把控制器或成品 mirror 與執行器放在同一大洲或同雲出口策略下。
跳過 frozen Xcode 與 CLT 組合的書面合約：無人值守機上差一個小版本，Codesign 與 Swift 驅動行為可能完全不同；沒有每週凍結清單就會在發版週集體炸。
認清誤判後，「要不要獨佔雲端節點」的結論應寫成憑證邊界、映像邊界、佇列擁有者、區域親和四行欄位，並可與 儲存與記憶體選配 中的檔位敘事對齊：先有穩定資料面與統一記憶體水位，再給 GitLab 或 Jenkins 分配命名空間。
若您正在評估「先近區按日試水，再切美東長期池」，建議把兩次驗收的佇列 P95、解析占比與漂移事件次數都保留下來，比較差異是否主要來自下載耗時還是執行器設定本身；這能避免採購覆盤時把「網路快」誤寫成「架構更優」。當外包或 QA 也要登入同一節點時，應把互動工作階段與批次佇列拆到不同系統使用者或至少不同標籤池，並把回收流程寫進與 多人共用治理 一致的工單範本。
對照表：GitLab executor、Jenkins 連線方式與 GitHub Actions Runner 的職責邊界
本節刻意不把「獨佔雲端 macOS」寫成與某一編排器強綁定：即便組織裡三套並存，只要把執行器視作可被標籤尋址的長期資產，財務與法務依然能把它與蘋果託管路徑並排放在一張表上。與 Xcode Cloud 混搭 的結論一致：短 spike 可走託管，長尾與簽章鏈路宜落獨佔。GitLab 與 Jenkins 的常見差異在於：前者把流水線宣告 closer to 倉儲庫，後者把長尾外掛與簽核流 closer to 控制器；執行器側的磁碟與鑰匙圈治理卻是同一套硬約束。
| 執行器形態 | 較合適的情境 | 您必須額外驗收的項 |
|---|---|---|
| GitLab shell | 單團隊、快速打通 iOS 建置、需要直接呼叫 xcodebuild | login 鑰匙圈與 CI 使用者分離、全域 brew 與 npm 前置詞凍結 |
| GitLab docker | 希望把相依安裝隔離在映像層、多專案復用同一 golden 映像 | Apple 授權與 docker 在 macOS 上的支援矩陣、卷掛載與 codesign 邊界 |
| GitLab SSH | 執行器在遠端 Mac、GitLab 只做排程 | StrictHostKey、跳板與稽核出口、與成品倉同區 |
| Jenkins inbound agent | 控制器在固定機房、執行器在雲端、需長連線回連 | TLS 往返 RTT、重連風暴、控制器與成品 mirror 的大洲對齊 |
| Jenkins SSH agent | 控制器主動推工作、網路策略更偏「出站白名單」 | Host key 輪換、sudo 與 launchd 槽位、並行 job 上限 |
| 維度 | GitLab CI 典型切口 | Jenkins 典型切口 | GitHub Actions（對照） |
|---|---|---|---|
| 並行語意 | resource_group 與平行矩陣 | Throttle 與 label 運算式 | concurrency 與 runs-on 標籤 |
| 憑證形態 | CI 變數、受保護分支與 environment | Credentials binding 與 folder 級權限 | OIDC、environment secrets |
| 與本文互鏈 | 成品同區與 MR 流水線 | 外掛長尾與簽核節點 | 見站內專文 |
先選執行器隔離層級與憑證邊界，再選編排器；最後再談「買幾核」才不會變成口號式擴容。
當您在獨佔池上考慮並聯第二臺機器的動機來自成品 RTT 而不是 CPU，應先對照 並聯資源決策 中的四類負載分叉，再決定是否同區擴容 Runner Fleet。若僅為了 Jenkins 控制器與雲端 Mac 之間的 TLS 抖動就加機器，往往應先做 mirror 與登錄服務同洲，而不是複製執行器。
標籤、resource_group 與 Jenkins label：把地理意圖與負載類型寫進可排程字串
獨佔雲端節點的價值在於同一套 Runner 或 Agent 二進位可在 launchd 下長期存活，而您的流水線卻仍可能用模糊標籤把 MR 煙測與夜間 notarize 搶在同一個池裡。做法是先把地理與倉儲庫意圖寫進自解釋標籤，再在 GitLab 的 resource_group 或 Jenkins 的 throttle 裡寫清優先權與互斥，避免平行矩陣在非高峰也把磁碟寫爆。更多網路出口與固定 IP 敘述見 說明中心 連線類文件，與本文並行閱讀可補全「執行器側」之外的組織策略。
下面範例刻意使用虛構區域標籤名，您應替換為組織內部已對齊的洲、國家與機房欄位；關鍵是標籤集合必須能映射回採購工單裡的 KVMNODE 區域與機型檔，這樣值班同仁接到告警時可以直接比對「這臺機當時在工單裡承擔的是哪條資料面」。
stages: [build, sign]
default:
tags: ["macos", "region-apac-1", "workload-mr"]
build_ios:
stage: build
resource_group: ios-binaries-${CI_PROJECT_ID}
script:
- xcodebuild -scheme "$SCHEME" -destination 'platform=iOS Simulator,name=iPhone 16' build
sign_pkg:
stage: sign
tags: ["macos", "region-usw-1", "workload-release"]
resource_group: notary-${CI_PROJECT_ID}
script:
- xcodebuild -exportArchive ...
提示：resource_group 會把互斥範圍寫進排程器語意層；Jenkins 側可用 throttle category 表達類似互斥，但欄位名不同，禁止混用概念口頭對齊。
若同時使用 GitLab 與 Jenkins 指向同一臺雲端 Mac，應為兩套編排器分配不同的 launchd Label 前置詞與日誌目錄，避免 stdout 互相覆寫；並在變更單裡強制填寫「本次變更影響哪一條編排器」，防止一半升級一半未升級的半凍結狀態長期存在。
六步：從裸機雲端 Mac 推進到可灰階的 GitLab 或 Jenkins 執行器池
凍結目標 Xcode 與 CLT 組合：在獨佔機用 xcodebuild -version 與 xcode-select -p 列印寫進 Runbook，並在週五凍結窗統一升 patch。
建立專用 CI 使用者與鑰匙圈分割：互動式登入與 security 匯入憑證分離，避免同一 login 鑰匙圈被人工與批次混用。
安裝並註冊 Runner 或 Agent：用 launchd 保持行程重啟策略，禁止長期依賴互動式 shell；GitLab 用 gitlab-runner register，Jenkins 依官方範本產生 plist。
先掛唯讀煙測流水線：不寫部署金鑰，僅驗證簽出、SPM 解析與本機快取命中率基線。
再掛簽章與公證鏈：把 notarytool 與應用程式專用密碼輪換寫進工單系統，金鑰不落盤為多份明文副本。
灰階並行與回滾：用資源群組或 throttle 分組平行觀察 P95，失敗則回滾映像 tag 而不是只重啟執行器。
六步全部走完後，應能在工單系統裡用同一套欄位描述「區域、機型檔、凍結 Xcode 批次號、佇列擁有者、回滾責任人」，並與 KVMNODE 側按日或按月租期欄位對齊；這樣從短期驗證切到長期池時不需要重寫敘述，只需改租期與標籤容量。
可引用觀測口徑與 M4 對比 M4 Pro 檔型分叉：三週窗口寫什麼給管理層
佇列 P95：同一資源群組內從排隊到第一段指令起跑的牆鐘時間，目標連續兩週低於 SLA 閾值；若 Xcode Cloud 流水線也同時執行，分拆標籤再比較。
解析占比：xcodebuild -resolvePackageDependencies 或與 SPM 等價階段占整條流水線的百分比，若超三成應優先映像與登錄服務 RTT 而不是加核。
漂移事件次數：每週因映像或 Xcode 切換導致的非合併相關紅建置次數；應趨向零並在變更單留痕。
注意：把 SaaS 託管分鐘數與獨佔裸金屬按月租對比時，若忽略簽章與映像治理人力，會系統性低估自託管 TCO；把 GitLab、Jenkins 與 GitHub 混在一個預算科目裡則會 double count 並行度。
檔型分叉上，Mac mini M4 16GB 與 256GB 較適合以 MR 煙測與輕量單 Scheme 為主的 GitLab shell 池；當平行矩陣、多 Xcode 並存或大型 DerivedData 與 notary 成品同機共存時，應評估 24GB 與 512GB 檔 是否仍足夠，否則進入 M4 Pro 64GB 與 2TB 或 並聯資源 分叉。採購說明裡建議同時寫明「峰值並行 job 數」與「峰值成品體積」兩行，避免只寫 CPU 型號導致驗收扯皮。
純桌面 Mac 或家用寬頻上的執行器往往要面對睡眠、上游電信業者 NAT 與不可稽核出口；巢狀虛擬化 macOS 實例則會引入 Metal 與程式碼簽邊界模糊。相較之下，可在新加坡、東京、首爾、香港與美東美西等點位合約化交付、把獨佔 Apple Silicon 與彈性租期寫進採購說明、並把出口與合規文件對齊的雲端節點，更適合長期承載 GitLab、Jenkins 與 GitHub 側交付鏈路的結合部。對於要把佇列指標與區域標籤固化為財務科目、減少「臨時加機器」口頭決策的團隊，KVMNODE 的 Mac mini 雲端租賃通常是更優解：獨佔硬體、完整設定檔梯度、透明區域與按日到按月可切換的租期，把試錯成本壓在驗證視窗而不是資本支出。檔位與下單路徑見 價格頁，網路與共站說明見 說明中心。
若您計畫把 Jenkins 控制器留在自建機房、僅把 macOS 執行器遷到雲上，務必在首週觀測 inbound TLS 的尾延遲；當尾延遲與佇列 P95 同步變差時，優先評估成品 mirror 與登錄服務同洲，而不是先把執行器從 M4 升到 M4 Pro。升級機型檔應發生在資料面已對齊之後，否則只是把慢網路搬到更大的統一記憶體裡。