2026-04-16 iOS CI 磁碟清理：模擬器執行時、封存與租賃雲端 Mac 上的 launchd 掃除
在香港、東京、首爾、新加坡與美國東部租賃的Mac mini M4建置機上，磁碟看似永遠夠用，直到 df -h 顯示資料卷可用空間低於約 12%——此後每一次 xcodebuild test 都像抽籤。本篇以2026-04-16為時間戳，說明在已隔離編譯快取的情況下為何仍會漲盤，用表格標出最大目錄，給出可複製的 simctl 維護指令，定義封存保留策略，附帶 launchd 掃除範本，並串聯 依作業隔離 DerivedData（2026-04-15） 與 無頭模擬器測試，讓衛生策略從編譯到測試端到端一致。
為何「已經在清 DerivedData」磁碟仍會滿
依作業設定 DERIVED_DATA_PATH 能避免編譯競態，但擋不住全域占用：為 Xcode 16.x 安裝的每個 iOS 執行時仍位於 /Library/Developer/CoreSimulator；一次 UI 測試可能增加 300–900 MB 裝置資料；每次封存都會複製 dSYM 與 bitcode 切片。若在同一主機輪替三個 Xcode 小版本卻未解除安裝舊執行時，團隊往往在察覺前已失去 80–140 GB。將磁碟遙測與佇列深度對齊，只有在掃除邊際收益遞減後再透過 定價頁擴容。
- 陳舊已啟動模擬器 會保持 CoreSimulator 掛載，阻礙刪除。
- 舊的 watchOS / tvOS 執行時 在只建置 iOS 目標時仍會長期存在。
- 封存 在共享 SSH 主機上常因無人認領保留政策而堆積。
- 部分映像上移到
/tmp的 xcresult 封包在重新開機後仍存在——需顯式掃除。
佔用地圖：容量躲在哪裡
| 路徑 / 區域 | 常見區間 | 可否自動化？ |
|---|---|---|
~/Library/Developer/Xcode/Archives |
累計約 15–120 GB | 可以，需基於日期的政策並先上傳物件儲存 |
~/Library/Developer/CoreSimulator/Devices |
約 8–60 GB | 部分——刪除不可用裝置並修剪媒體快取 |
/Library/Developer/CoreSimulator/Volumes（執行時） |
多版本約 25–90 GB | 謹慎——與所需 SDK 矩陣對齊 |
~/Library/Developer/Xcode/iOS DeviceSupport |
約 5–25 GB | 若政策允許，可刪除早於 180 天 的版本 |
/Users 與 /Volumes/builds 的 NVMe 卷可用空間低於 50 GB 時發頁；低於 25 GB 時硬停止接收新作業，避免封存中途核心寫入失敗。
維運實際在跑的 simctl 指令
僅在 CI 佇列報告零個活躍模擬器作業時執行，或先將 runner 打上維護標籤並排空後再操作。
xcrun simctl shutdown all
xcrun simctl delete unavailable
xcrun simctl erase all # 僅用於可丟棄的預覽機——未經批准切勿在共享生產型建置機上使用
為列出執行時並決定從 Xcode「平台」面板或 xcodebuild -downloadPlatform 流程解除安裝哪些套件，建議每週將 xcrun simctl list runtimes 輸出寫入設定儲存庫，使東京與新加坡節點保持一致。
封存：財務也能聽懂的保留算術
將 .xcarchive 視為受管制成品：上傳物件儲存後，本地依回滾政策保留 14 或 30 天再刪除。若合規要求90 天本地保留，應明確購買磁碟餘量——不要指望壓縮救命；對已壓縮切片 zip 很少能優於 35%。
| 保留政策 | 約月度成長（單一應用、每週封存） | 緩解手段 |
|---|---|---|
| 本地 7 天 | 12–20 GB | 夜間 tar + 上傳 + 刪除 |
| 本地 30 天 | 45–70 GB | 分層儲存 + 校驗和驗證 |
| 無限期「以防萬一」 | 無上限 | 在共享租賃 Mac 上禁止 |
使用 launchd 的掃除作業（無點維運）
將維護封裝為 CI 使用者擁有的非互動指令稿；日誌寫入 ~/Library/Logs/ci-janitor.log；若任一步單次刪除超過 15 GB 則非零結束以便 Slack 留痕。按區域在週日 03:00本地時間排程——香港的週日清晨在美西仍是週六晚間，跨時區團隊請錯峰。
~/Library/Developer/Xcode/UserData——程式碼片段與中斷點存在其中；工程師會抗議，你也會重新開啟「神秘紅建置」工單。
與 DerivedData 及測試策略搭配
全域掃除後，仍需保證每條流水線依作業設定 DERIVED_DATA_PATH，詳見 2026-04-15 隔離文章。對 UI 繁重的套件，請重讀 無頭模擬器測試 以限制平行 destination，避免掃除與活躍的 SimulatorTrampoline 行程衝突。
激進掃除後的觀察點
首次掃除後的作業可能多花 4–11 分鐘 重新下載符號或重建 DeviceSupport。請追蹤 p95 建置時間 48 小時；若漲幅超過 22%，表示政策過激進——從備份恢復或放寬保留。
常見問題：租賃 Apple Silicon 上的磁碟衛生
| 問題 | 簡要回答 |
|---|---|
| 是否應把 Archives 軟連結到 NFS？ | 僅當鏈路延遲足夠低；否則採上傳後刪除本地。 |
| Apple Silicon 會壓縮 CoreSimulator 資料嗎？ | APFS 克隆對部分範本有幫助；不要據此做容量核算。 |
| 誰擁有掃除指令稿？ | 平台團隊 + 輪值 on-call，文件見 說明中心。 |
區域、NVMe 與何時再加一台 Mac
磁碟壓力常常是單台主機負載過多的代理指標。若掃除每週可回收 >40 GB 而可用空間仍長期在 20% 附近徘徊，應在 JP 與 SG 建置機之間拆分團隊，或增加第二台 美國東部 節點——到 Git 與 App Store Connect 的延遲與位元組數同樣重要。用 定價 比較裸金屬檔位；將 部落格索引 加入書籤以追蹤簽章、公證與 OpenClaw 手冊。
結論：在共享租賃 Mac 上，全域模擬器與封存衛生不是可選項——它決定夜間建置是可預測還是「直到有人 SSH 上去才變綠」。自動化、可度量，並與依作業的 DerivedData 紀律配套。
