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 代理把控制连接回连到控制器，又未把节点标签与 Job 的 SCM 区域写清，就会出现「控制器在美东、仓库在新加坡、执行器在香港」这类逻辑可通、物理很慢的组合。独占云 Mac 的价值在于把执行器变成可命名、可冻结镜像、可审计出口的长期资产；若仍按「谁喊得响就给谁加标签」临时扩容，只是把排队噪声从 SaaS 队列搬到了自家标签池里。
当你在新加坡、日本、韩国、香港与美东美西之间分配开发者与外包 QA 时，若私有制品仓、容器 registry 与 Git LFS 仍落在单一地理域，而 Runner 或 Agent 却按人力就近随手挂到另一域，解析阶段与制品搬运会吃掉大量墙钟时间，此时再堆核数只会复制误解。应先回到 多地区选区与租期 把数据面与执行器同洲写进合同，再对照 GitHub Actions Runner 里关于组织级缓存与并发组的叙述，决定「哪条链路留在 GitHub、哪条必须落在 GitLab 或 Jenkins」。
另一条常被低估的线是人机混用：白天有人用 Screen Sharing 改 Xcode 路径、夜里批处理仍读同一 login keychain，表现为「偶发红」实则是竞态。若团队已阅读 多人共用节点治理，应把 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 语义：并行矩阵在低谷也会写爆磁盘，财务看到的是「又买了一台」而不是「队列 owner 缺失」。
把控制器与执行器的 TLS 往返当成零成本：跨洲 inbound 连接在晚高峰会放大 tail latency，应把控制器或制品 mirror 与执行器放在同一大洲或同云出口策略下。
跳过 frozen Xcode 与 CLT 组合的书面合同：无人值守机上差一个小版本，Codesign 与 Swift 驱动行为可能完全不同；没有每周冻结清单就会在发版周集体炸。
认清误判后，「要不要独占云节点」的结论应写成密钥边界、镜像边界、队列 owner、区域亲和四行字段，并可与 存储与内存选配 中的档位叙事对齐：先有稳定数据面与统一内存水位，再给 GitLab 或 Jenkins 分配命名空间。
若你正在评估「先近区按天试水，再切美东长期池」，建议把两次验收的队列 P95、解析占比与漂移事件次数都保留下来，比较差异是否主要来自依赖下载耗时还是执行器配置本身；这能避免采购复盘时把「网络快」误写成「架构更优」。当外包或 QA 也要登录同一节点时，应把交互式会话与批处理队列拆到不同系统用户或至少不同标签池，并把回收流程写进与 多人共用治理 一致的工单模板。
对照表：GitLab executor、Jenkins 连接方式与 GitHub Actions Runner 的职责边界
本节刻意不把「独享云 macOS」写成与某一编排器强绑定：即便组织里三套并存，只要把执行器视作可被标签寻址的长期资产，财务与法务依然能把它与苹果托管路径并排放在一张表上。与 Xcode Cloud 混搭 的结论一致：短 spike 可走托管，长尾与签名链路宜落独占。GitLab 与 Jenkins 的常见差异在于：前者把流水线声明 closer to repo，后者把长尾插件与审批流 closer to controller；执行器侧的磁盘与钥匙串治理却是同一套硬约束。
| 执行器形态 | 更合适的场景 | 你必须额外验收的项 |
|---|---|---|
| GitLab shell | 单团队、快速打通 iOS 构建、需要直接调用 xcodebuild | login keychain 与 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 或 Agent Fleet。若仅为了 Jenkins 控制器与云 Mac 之间的 TLS 抖动就加机器，往往应先做 mirror 与 registry 同洲，而不是复制执行器。
标签、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 keychain 被人工与批处理混用。
安装并注册 Runner 或 Agent：用 launchd 保持进程重启策略，禁止长期依赖交互 shell；GitLab 用 gitlab-runner register，Jenkins 按官方模板生成 plist。
先挂只读冒烟流水线：不写部署密钥，仅验证检出、SPM 解析与本地缓存命中率基线。
再挂签名与公证链：把 notarytool 与应用专用密码轮转写进工单系统，密钥不落盘为多份明文副本。
灰度并发与回滚：用资源组或 throttle 分组并行观察 P95，失败则回滚镜像 tag 而不是只重启执行器。
六步全部走完后，应能在工单系统里用同一套字段描述「区域、机型档、冻结 Xcode 批次号、队列 owner、回滚责任人」，并与 KVMNODE 侧按天或按月租期字段对齐；这样从短期验证切到长期池时不需要重写叙事，只需改租期与标签容量。
可引用观测口径与 M4 对比 M4 Pro 档型分叉：三周窗口写什么给管理层
队列 P95：同一资源组内从排队到第一段脚本起跑的墙钟时间，目标连续两周低于 SLA 阈值；若 Xcode Cloud 流水线也同时运行，分拆标签再比较。
解析占比：xcodebuild -resolvePackageDependencies 或与 SPM 等价阶段占整条流水线的百分比，若超三成应优先镜像与 registry 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 的 tail latency；当 tail 与队列 P95 同步变差时，优先评估制品 mirror 与 registry 同洲，而不是先把执行器从 M4 升到 M4 Pro。升级机型档应发生在数据面已对齐之后，否则只是把慢网络搬到了更大的统一内存里。