2026年短周期突发构建：GitLab CI 自托管 macOS Runner 接云 Mac 的 Shell Executor、缓存键与标签策略——和 GitHub Actions 混用时的决策矩阵与可执行参数 FAQ

短周期「突发」构建最怕两件事：排队把窗口挤没、缓存把环境悄悄弄脏。把 GitLab Runner 注册到云 Mac 上并选用 shell 执行器，可以直接复用你在机器上已经验证过的 Xcode、Ruby/CocoaPods 与签名钥匙串，省去 Docker on Mac 或 SSH 远程脚本的额外一层抽象；代价是同一用户主目录下的全局状态要靠自己用标签与缓存键管住。下文按我们线上常用的参数写，可直接改仓库里的 .gitlab-ci.yml 试用。

Shell Executor：何时值得接云 Mac

当 Job 主要是 xcodebuild、Archive、notary 或依赖本机钥匙串的脚本时，shell 比容器执行器更省事：路径、权限与 GUI 会话（若需要）都和人工登录排障一致。建议为 Runner 单独建系统用户或至少独立 Home，避免与人工桌面共用 DerivedData；并发大于 1 时务必评估磁盘 IO 与 codesign 锁竞争，否则 wall time 会被尾延迟拖长。

缓存键：让「快」不牺牲「准」

GitLab 的 cache:key:files 建议至少纳入 Gemfile.lock、Podfile.lock、Package.resolved 中与编译相关的锁文件；Xcode 大版本升级时额外拼一段 MACOS_CI_IMAGE_ID 变量，避免旧 DerivedData 混进新工具链。policy 用 pull-push 适合主干高频分支，只对发布分支或 nightly 打开全量 push，可减轻对象存储写放大。

cache:
  key:
    files:
      - Gemfile.lock
      - Podfile.lock
      - YourApp.xcworkspace/xcshareddata/swiftpm/Package.resolved
    prefix: "${CI_COMMIT_REF_SLUG}-xcode${XCODE_VERSION}"
  paths:
    - .cocoapods/
    - ~/Library/Developer/Xcode/DerivedData/
  policy: pull-push

标签策略：burst、steady 与「只跑云 Mac」

用 tags 把 Runner 分成 mac-burst（弹性云节点，允许抢占与较短超时）与 mac-steady（合同内固定配额，跑签名与上架）。默认流水线只打 burst；需要钥匙串解锁或人工值守的步骤单独 job 并打 steady，避免突发任务挤占关键路径。与「第二条 macOS 流水线还是拆 Linux Job」的取舍可对照：2026年短周期冲刺：加开第二条macOS CI流水线还是把Job拆到Linux代理？排队成本与密钥隔离决策矩阵与FAQ。

和 GitHub Actions 混用：决策矩阵（简版）

双平台常见动机是：开源侧仍在 GitHub，私有制品与内网依赖在 GitLab。原则是「谁离代码与密钥最近，谁跑重 Job」。若 GitHub 已有成熟的 macOS workflow，可把轻量检查留在 Actions，把需要内网缓存或 GitLab Registry 的步骤迁到自托管 Runner；反之亦然。注意两边都开缓存时，用不同 bucket 前缀与 key，避免同名 key 互相覆盖。

ios_burst:
  stage: build
  tags: [mac-burst, shell]
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  variables:
    GIT_STRATEGY: fetch
    FASTLANE_OPT_OUT_USAGE: "1"
  script:
    - xcodebuild -version
    - bundle exec fastlane ci_unit