2026-04-16 Nettoyage disque iOS CI : runtimes Simulateur, archives et janitors launchd sur Mac cloud loué

Les builders Mac mini M4 loués à Hong Kong, Tokyo, Séoul, Singapour et US Est semblent infinis jusqu'à ce que df -h affiche moins de 12 % de libre sur le volume de données — puis chaque xcodebuild test devient une loterie. Daté du 2026-04-16, ce guide explique pourquoi le disque grossit malgré des caches de compilation isolés, cartographie les plus gros dossiers, liste la maintenance simctl prête à coller, définit une politique de rétention des archives, fournit un gabarit launchd, et renvoie vers l'isolation DerivedData par job (2026-04-15) et les tests simulateur sans interface pour une hygiène bout-en-bout.

Pourquoi le disque Mac cloud se remplit alors que « nous nettoyons déjà DerivedData »

Un DERIVED_DATA_PATH par job évite les courses de compilation, pas les consommateurs globaux : chaque runtime iOS installé pour Xcode 16.x reste sous /Library/Developer/CoreSimulator ; un test UI peut ajouter 300 à 900 Mo de données appareil ; chaque archive duplique dSYM et tranches bitcode. Les équipes qui font tourner trois mineures Xcode sur un hôte sans désinstaller les anciens runtimes perdent souvent 80 à 140 Go avant de s'en apercevoir. Couplez télémétrie disque et profondeur de file ; ne montez en charge via les tarifs qu'après avoir épuisé le levier des janitors.

• Simulateurs bootés obsolètes gardent les montages CoreSimulator et bloquent la suppression.
• Anciens runtimes watchOS / tvOS persistent quand seules des cibles iOS sont compilées.
• Les archives s'accumulent sur hôtes SSH partagés faute de propriétaire de rétention.
• Des paquets xcresult déplacés vers /tmp survivent au reboot sur certaines images — balayez-les explicitement.

Carte d'empreinte : où se cachent les gigaoctets

Chemin / zone	Plage typique	Automatisable ?
~/Library/Developer/Xcode/Archives	15 à 120 Go cumulés	Oui, politique par âge + upload stockage objet d'abord
~/Library/Developer/CoreSimulator/Devices	8 à 60 Go	Partiel — supprimer unavailable + élaguer caches média
/Library/Developer/CoreSimulator/Volumes (runtimes)	25 à 90 Go multi-version	Prudent — coordonner avec la matrice SDK requise
~/Library/Developer/Xcode/iOS DeviceSupport	5 à 25 Go	Oui pour versions > 180 jours si la politique l'autorise

Commandes simctl que les opérateurs lancent vraiment

Exécutez-les seulement lorsque la file CI signale zéro job simulateur actif, ou après avoir vidé les runners avec une étiquette de maintenance.

xcrun simctl shutdown all xcrun simctl delete unavailable xcrun simctl erase all # uniquement sur hôtes preview jetables — jamais sur builders partagés prod-like sans validation

Pour lister les runtimes et décider quoi désinstaller depuis Xcode ou xcodebuild -downloadPlatform, capturez xcrun simctl list runtimes chaque semaine dans votre dépôt de config afin d'aligner Tokyo et Singapour.

Archives : arithmétique de rétention que la finance comprend

Traitez .xcarchive comme un artefact réglementé : uploadez vers le stockage objet, conservez localement 14 ou 30 jours selon la politique de rollback, puis supprimez. Si la conformité impose 90 jours locaux, achetez explicitement de la marge disque ; ne comptez pas sur la compression : zip dépasse rarement 35 % sur des tranches déjà compressées.

Rétention	Croissance mensuelle approx. (une app, archive hebdo)	Atténuation
7 jours local	12 à 20 Go	Tar + upload + suppression nocturne
30 jours local	45 à 70 Go	Stockage hiérarchisé + vérification de checksum
∞ « au cas où »	Illimitée	Interdit sur Mac loués partagés

Tâches janitor avec launchd (sans ClickOps)

Encapsulez la maintenance dans un script non interactif appartenant à l'utilisateur CI ; journalisez vers ~/Library/Logs/ci-janitor.log ; sortez non-zéro si une étape supprime > 15 Go d'un coup pour laisser une trace Slack. Planifiez le dimanche 03:00 heure locale par région — le dimanche matin à Hong Kong est encore samedi soir en Californie, décalez si l'équipe est globale.

Coupler avec DerivedData et stratégie de tests

Après un nettoyage global, chaque pipeline doit toujours fixer DERIVED_DATA_PATH par job comme dans l'article d'isolation 2026-04-15. Pour les suites UI lourdes, relisez les tests headless pour plafonner les destinations parallèles afin que les janitors n'affrontent pas des processus SimulatorTrampoline actifs.

Points de vigilance après nettoyage agressif

Attendez-vous à ce que le premier job post-janitor passe +4 à +11 minutes à retélécharger des symboles ou reconstruire DeviceSupport si vous avez taillé DeviceSupport. Suivez le p95 de build pendant 48 heures ; si la hausse dépasse 22 %, la politique était trop agressive — restaurez depuis sauvegarde ou élargissez la rétention.

FAQ : hygiène disque sur Mac Apple Silicon loués

Question	Réponse courte
Faut-il lier symboliquement Archives vers NFS ?	Seulement avec des liens à faible latence ; sinon upload puis suppression locale.
Apple Silicon compresse-t-il les données CoreSimulator ?	Les clones APFS aident certains modèles ; ne vous en servez pas pour la comptabilité.
Qui possède le script janitor ?	Équipe plateforme + astreinte documentée dans l'aide.

Régions, NVMe et quand ajouter un autre Mac

La pression disque est souvent un proxy de trop de charge sur un seul hôte. Si les janitors récupèrent > 40 Go par semaine et que vous frôlez encore 20 % libre, séparez les équipes entre builders JP et SG ou ajoutez un second nœud US Est — la latence vers Git et ASC compte autant que les octets. Comparez les niveaux bare-metal sur les tarifs ; gardez l'index du blog pour signature, notarisation et runbooks OpenClaw.

En bref : l'hygiène globale simulateur + archives n'est pas optionnelle sur Mac loués partagés — c'est la différence entre des nightlies prévisibles et « rouge jusqu'à ce que quelqu'un SSH ». Automatisez, mesurez, couplez à une discipline DerivedData par job.