2026-04-16 iOS-CI-Speicherbereinigung: Simulator-Runtimes, Archive und launchd-Janitors auf gemietetem Cloud-Mac
Gemietete Mac mini M4-Builder in Hongkong, Tokio, Seoul, Singapur und US-Ost wirken unendlich, bis df -h unter 12 % frei auf dem Daten-Volume fällt — dann wird jedes xcodebuild test zur Lotterie. Dieses 2026-04-16-Playbook erklärt, warum Platte wächst trotz isolierter Compile-Caches, kartiert große Verzeichnisse, listet kopierbare simctl-Wartung, definiert Archiv-Aufbewahrung, liefert ein launchd-Template und verlinkt DerivedData-Isolation pro Job (2026-04-15) sowie kopflose Simulator-Tests für eine durchgängige Hygiene-Story.
Warum Cloud-Mac-Platten voll werden, obwohl „wir räumen schon DerivedData“
Pro-Job-DERIVED_DATA_PATH behebt Compile-Races, nicht globale Verbraucher: jede für Xcode 16.x installierte iOS-Runtime liegt weiter unter /Library/Developer/CoreSimulator ; UI-Tests können 300–900 MB Gerätedaten hinzufügen; jedes Archiv dupliziert dSYMs und Bitcode-Slices. Teams, die drei Xcode-Minors auf einem Host rotieren, ohne alte Runtimes zu deinstallieren, verlieren oft 80–140 GB, bevor es auffällt. Koppeln Sie Disk-Telemetrie mit Queue-Tiefe und skalieren Sie über Preise erst, wenn Janitors nichts mehr bringen.
- Veraltete gebootete Simulatoren halten CoreSimulator-Mounts und blockieren Löschungen.
- Alte watchOS/tvOS-Runtimes bleiben, obwohl nur iOS gebaut wird.
- Archive häufen sich auf geteilten SSH-Hosts ohne Aufbewahrungsbesitzer.
- xcresult-Bundles unter
/tmpüberleben auf manchen Images den Reboot — explizit fegen.
Fußabdruck-Karte: wo die Gigabytes liegen
| Pfad / Bereich | Typische Spanne | Automatisierbar? |
|---|---|---|
~/Library/Developer/Xcode/Archives |
15–120 GB kumuliert | Ja, mit Altersrichtlinie + zuerst Objektspeicher-Upload |
~/Library/Developer/CoreSimulator/Devices |
8–60 GB | Teilweise — unavailable löschen + Medien-Caches stutzen |
/Library/Developer/CoreSimulator/Volumes (Runtimes) |
25–90 GB multi-version | Vorsicht — mit SDK-Matrix abstimmen |
~/Library/Developer/Xcode/iOS DeviceSupport |
5–25 GB | Ja für Versionen älter 180 Tage, wenn Richtlinie erlaubt |
/Users und /Volumes/builds weniger als 50 GB frei sind; neue Jobs hart stoppen unter 25 GB, um Kernel-Schreibfehler mitten im Archiv zu vermeiden.
simctl-Befehle, die Betrieb wirklich ausführt
Nur ausführen, wenn die CI-Warteschlange null aktive Simulator-Jobs meldet — oder Runner zuerst per Wartungslabel leeren.
xcrun simctl shutdown all
xcrun simctl delete unavailable
xcrun simctl erase all # nur auf Wegwerf-Preview-Hosts — nie ohne Freigabe auf geteilten prod-ähnlichen Buildern
Für Runtime-Listen wöchentlich xcrun simctl list runtimes ins Config-Repo schreiben, damit Tokio und Singapur gleich bleiben.
Archive: Aufbewahrungs-Mathe, die Finance versteht
.xcarchive wie regulierte Artefakte behandeln: in Objektspeicher laden, lokal 14 oder 30 Tage je Rollback-Politik, dann löschen. Wenn Compliance 90 Tage lokal verlangt, Disk-Headroom explizit kaufen — zip schlägt auf bereits komprimierten Slices selten 35 %.
| Aufbewahrung | Ca. monatliches Wachstum (eine App, wöchentliches Archiv) | Minderung |
|---|---|---|
| 7 Tage lokal | 12–20 GB | Nächtlich tar + Upload + löschen |
| 30 Tage lokal | 45–70 GB | Tiered Storage + Checksummen-Prüfung |
| ∞ „nur für den Fall“ | unbegrenzt | auf geteilten gemieteten Macs verboten |
Janitor-Jobs mit launchd (ohne ClickOps)
Wartung in nicht-interaktives Skript des CI-Benutzers packen; nach ~/Library/Logs/ci-janitor.log loggen; non-zero beenden, wenn ein Schritt > 15 GB auf einmal löscht, damit Slack eine Spur hat. Sonntag 03:00 lokal pro Region — Hongkong-Sonntag früh ist in Kalifornien noch Samstagabend, staffeln.
~/Library/Developer/Xcode/UserData komplett löschen — Snippets und Breakpoints leben dort; Revolte und „mysteriöse rote Builds“ kehren zurück.
Mit DerivedData- und Teststrategie koppeln
Nach globalem Cleanup weiterhin pro Pipeline DERIVED_DATA_PATH setzen wie in Artikel 2026-04-15. Für UI-lastige Suites kopflose Tests erneut lesen, parallele Destinations zu deckeln, damit Janitors nicht gegen laufende SimulatorTrampoline-Prozesse kämpfen.
Watchpoints nach aggressivem Cleanup
Erster Post-Janitor-Job kann +4 bis +11 Minuten für Symbol-Downloads oder DeviceSupport brauchen. p95-Build-Zeit 48 Stunden tracken; > 22 % Sprung bedeutet zu aggressive Politik — aus Backup wiederherstellen oder Aufbewahrung weiten.
FAQ: Disk-Hygiene auf gemieteten Apple-Silicon-Macs
| Frage | Kurzantwort |
|---|---|
| Archive per Symlink auf NFS? | Nur bei niedriger Latenz; sonst uploaden und lokal löschen. |
| Komprimiert Apple Silicon CoreSimulator-Daten? | APFS-Klone helfen manchen Templates — nicht für Kapazitätsplanung. |
| Wem gehört das Janitor-Skript? | Plattform-Team + Rufbereitschaft in Hilfe dokumentieren. |
Regionen, NVMe und wann ein zweiter Mac nötig ist
Disk-Druck ist oft ein Proxy für zu viel Last auf einem Host. Wenn Janitors wöchentlich > 40 GB zurückholen und Sie trotzdem ~20 % frei kitzeln, Teams zwischen JP- und SG-Buildern splitten oder zweiten US-Ost-Knoten — Latenz zu Git und ASC zählt genauso wie Bytes. Preise für Bare-Metal-Stufen vergleichen; Blog-Index für Signierung, Notarisierung und OpenClaw-Runbooks bookmarken.
Fazit: globale Simulator- + Archiv-Hygiene ist auf geteilten gemieteten Macs Pflicht — der Unterschied zwischen planbaren Nightlies und „rot bis jemand SSH macht“. Automatisieren, messen, mit DerivedData-Disziplin pro Job koppeln.
M4-Builder mit Luft nach oben mieten
HK · JP · KR · SG · US · SSH / VNC
