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 雲端主機