Mac mini 云主机上的 CI/CD：GitHub Actions 自托管 Runner 与可审计算力单元

很多团队在找Mac mini 云主机时，真正要解决的是：没有本地 Mac，却要做 iOS / Xcode 构建，或要把GitHub Actions 自托管 Runner放在固定出口、可审计的环境里。OpenClaw 一类编排器负责触发顺序、命令与回执；ZavCloud 交付的是柜内物理独占的 Mac mini M4——原生macOS、静态 IPv4、1Gbps 独享骨干，以及VNC 远程桌面/ SSH 访问。把两层写进同一份运行手册，才能把「云端 Mac」从口号变成可复现的 Mac 云托管单元。

为什么 CI 要落在「云端 Mac」而不是普通 VPS？

普通 LinuxVPS可以跑大量后端任务，但无法替代 Apple 工具链：签名、Archive、部分测试与模拟器行为都依赖真实 macOS。所谓「Mac VPS」若实为嵌套虚拟化，往往在性能与合规上踩坑。ZavCloud 的Mac 云服务器租用按独享实例交付——整机内存与 NVMe 不与邻居共享，适合作为长期在线的self-hosted runner宿主，也适合与Core ML 批推理错峰共用同一台机器。

在 Mac mini 云主机上跑 GitHub Actions Runner

自托管 Runner 的核心价值是环境固定：Xcode 版本、证书钥匙串、Fastlane 配置与依赖缓存都留在同一台云端 Mac上，避免 GitHub 托管 macOS 队列排队或镜像漂移。建议做法：

• 为每台Mac mini 租用实例单独注册 Runner，标签区分地域（如hk-m4、sg-m4）
• 工作目录按RUN_ID隔离，回执写入 Git SHA、Xcode build、镜像指纹
• 大仓库git fetch与符号上传单独计时，避免把网络抖动当成编译变慢
• 首次配置可用VNC完成钥匙串与证书导入，日常构建走 SSH / Actions

带宽与 Mac hosting：什么要写进 SLA 旁边？

流水线里Git fetch、依赖缓存与崩溃符号上传会叠加在同一条链路上。独享骨干的意义是：构建尾延迟不被他人流量拉高。在合规场景里，把「带宽质量」与历史 P95 一起存档，比「高速网络」更有参考价值。节点地域（香港、东京、新加坡、美东等）以下单页为准，构建与制品上传尽量选同一侧出口。

两种接入路径

路径 A：SSH + 环境变量。编排器把WORKTREE与VPSSPARK_RUN_ID传入，任务结束后写回 metadata。适合首次把 iOS 构建迁上Mac cloud的团队。

路径 B：Webhook + 工单。任务结束推送回执；开关机等硬件操作在工单留痕，审计不依赖 CI 日志。两种路径可并存：日常构建用 SSH，异常扩容走工单。

无论哪种方式，建议把「编译成功」与「制品已签名」分开打点——构建完成不等于可分发。

运行契约片段（与编排器对接）

# 会话级：固定工作副本，便于算力单元与回执对齐
export VPSSPARK_RUN_ID="${CI_PIPELINE_ID:-local}"
export WORKTREE="$HOME/builds/$VPSSPARK_RUN_ID"

# 回执四元组：镜像 ID / Xcode build / Git SHA / WORKTREE
echo "$IMAGE_ID $XCODE_BUILD $GIT_SHA $WORKTREE" > metadata.txt

• 观测— 分离网络阶段与编译阶段计时
• 访问— 证书与 GUI 走 VNC，自动化走 Runner / SSH
• 下单 — 在线租用 Mac mini 云主机