維運 / CI·CD 2026年4月25日

2026-04-25 在租用的雲端 Mac 上，xcodebuild test 程式碼覆蓋率、xcresult 轉 JUnit 與 PR 閾值（港 / 日 / 韓 / 新 / 美）

MacXCode 技術團隊 2026年4月25日 約 18 分鐘閱讀

已在 Apple Silicon 租用的 Mac mini M4 上排程 無頭 xcodebuild test 的 iOS 與 macOS 團隊，仍常僅憑單一 結束代碼 與 CI 廠商介面紅/綠格合併 PR。本 2026-04-25 文把「測試通過」與「能說明本週品質如何變化」對齊：以 -resultBundlePath 指向 隔離建置根 下的 每作業 目錄、-enableCodeCoverage YES 產出 LLVM profdata、匯出 JUnit XML（xcresulttool 或您信任的封裝），並以 xccov 或自研解析實施行覆蓋率政策。它與 測試計畫 + 並行 xcresult 互補而非替代；編譯器閘道見 Swift 6 嚴格並行；本文是同一流水線的 測試構件與合併訊號 側。同日主線 OpenClaw：OpenClaw doctor 與模型白名單排查。

除了結束代碼 0，PR 閘道還應看見什麼

健全閘道攜帶三類包：(1) PR 系統可 標註 單測結果與不穩定的 junit（或 xunit）；(2) 可在 Xcode 深調的 已合併 或單一 .xcresult，以與 xcresult 隔離工單相同的 保留 策略壓縮為構件；(3) 可按政策做行/分支的 覆蓋率 摘要，並對合併基做 差分，使刪死碼的重構不算迴歸。在 港 / 日 / 韓 / 新 / 美 多 SSH 主機扇出時，閘道必須定義在 依目的地分片 後的 聚合 指標上——除非政策明確只涵蓋部分 target，否則不要讓某分片的 profdata 成為唯一敘事。延遲數字要與中繼資料列印的機器池標籤 配對，避免把東京 冷 模擬器與美東 熱 模擬器當公平 A/B。

關鍵 xcodebuild 參數：結果包、覆蓋率、目的地

固定 DEVELOPER_DIR=/Applications/Xcode.app 與可自控的 模擬器 -destination 字串，不要漂在「未點名的 最新 iOS」上。最小顯式模式：

DEVELOPER_DIR=/Applications/Xcode.app xcodebuild test -workspace App.xcworkspace -scheme App -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' -enableCodeCoverage YES -resultBundlePath "$CI_ROOT/Test-$(date +%s).xcresult" -derivedDataPath "$CI_DERIVED/job-$CI_JOB_ID" -parallel-testing-enabled YES CODE_SIGNING_ALLOWED=YES

在分片作業調整 -only-testing / -skip-testing；由知道如何合併的 協調 作業收斂。僅在有文件的 不穩定預算 下使用 -retry-tests-on-failure——無限重試會掩蓋 簽章/鑰匙圈 類問題。若已單獨跑 Swift 6 嚴格 階段，除非 scheme 真實拆分，否則不要在兩軌重複同一批單元 測試——重複覆蓋率浪費共享 NVMe 分鐘。

從 .xcresult 到 JUnit：無頭可跑的匯出

跑 macOS 的 CI 暴露 xcresulttool：把 測試 與 診斷 匯出為結構化 JSON 或 JUnit，視您釘選的 Xcode 參數而定。常見流程：(1) 傳給 -resultBundlePath 的路徑必須每跑唯一，且不在指向共享 NFS 的符號鏈上；(2) 跑完以 xcresulttool get --format json 做包體檢；(3) 為您的平台轉成 JUnit——許多團隊鎖一層很薄的 Ruby/Node 轉接；關鍵是每個 testcase 有穩定的 testsuite 名與 classname 以便 PR UI 對 重試 去重。若 合併 多個 xcresult，優先用 Xcode 的 merge 或文件的時間升序，當同一識別的 testStatus 衝突時拒合併。把原始 xcresult 像 模擬器 深排那樣送入冷儲，別只留 XML。

LLVM profdata、xccov 與可辯護的閾值

在 -enableCodeCoverage YES 下，編譯與連結會產出可用 xcrun llvm-profdata merge 合併、以 xcrun xccov view --report 或符合政策的 report 模式檢查的資料。務實政策：對自有的 應用 與 核心框架 模組設地板，以入庫的明確 排除表 去掉產生碼與第三方——未列出 的第三方不應默默吃掉團隊預算。自託管 runner 遷移後數字要對齊：同一 git SHA 在兩地應對齊源檔 雜湊，但增量 覆蓋率在某一主機略過 target 時可能不同——這也是嚴格軌常完全關增量的原因。若同一晚 上傳 dSYM 又動覆蓋率，確保 dSYM 流水線與您以為交付的 bitcode/LLVM 構件一致。

CI 護欄： 當 xccov 無法開啟 profdata 路徑時就讓建置失敗——默不作聲把覆蓋率當「0%」還放行 是 2026 年未測 diff 上線後再怪儀表板的做法。

分片 test 作業：先合併再閘道

依 -only-testing:Target/Class 或依裝置拆分時，每片自有 profdata 與 xcresult。協調器上的合併閘道應：(1) 確認每片 結束 並上傳構件；(2) 在單次 xccov 呼叫前 合併 profdata；(3) 匯聚 JUnit，對某片刻意缺席的套件標為 skipped。若分片因基礎設施搶占遺失，除非有書面「可缺片」規則（罕用且非預設），否則合併應判失敗。與 M4 扇出 同讀：並行只有在構件平面與覆蓋率能序列化回單份報告時才有幫助。

症狀 / 層次 / 處理

症狀 層次 處理 / 驗證
測完覆蓋率卻 0% 建置設定 / target 成員 檢查 scheme 已啟用 Code Coverage、target 以覆蓋率旗標編譯
JUnit 空但介面顯示通過 工具匯出 在主機 Xcode 上驗證 xcresulttool 輸出；勿信廠商空殼
兩台機行率差巨大 分支 / 增量 / 分片 對閘道關增量；合併 profdata；固定 destination

若本機也跑 OpenClaw 閘道，不要 在代理間共享單一路徑 /tmp——您的 TMPDIR 應已依作業隔離。對發佈建置，遠端 archive 與 App Store Connect API 匯出 IPA 是同一信任鏈的下游：CI 的測試+覆蓋率應落在您要打標發佈的同一條分支身分 上，外加您寫明的推進延遲。

常見問題：多區域 Mac 池中的品質閘道

問題 實務建議
是否以分支覆蓋率為合併阻塞？ 視語言與工具而定；對 PM 行率更好講，安全關鍵模組可再加分支率。
xcresult zip 留多久？ 與事故 SLA 對齊——14+ 天 常見；1–2 TB 租約可留更久。
矩陣裡先美東還是亞洲？ 互動式複現多數提交者最近區域；完整 矩陣在發版時跑。

為何為這類負載租 Mac mini M4

模擬器與覆蓋率任務更常受 CPU+NVMe+inode 限制而非 GPU。MacXCode 多區域的裸金屬 Mac mini M4 提供可預期 I/O 與足量 RAM 讓多個 CoreSimulator 根 預熱 而不與 OpenClaw 閘道同機搶鄰居雜訊。某區需要第二條通道降 p95 時，用 方案頁 擴容，而不是三支團隊硬擠 512 GB 碟。僅偶爾要人眼看 GUI 時，VNC 仍是破窗方案——SSH + 構件 應扛住 2026 的週更節奏。

在區域內做可重現的 iOS 測試 CI

M4 · 預設 SSH · 1–2 TB 選項