Points clés
- Suivez à la fois
df -hetdf -ih: une saturation d’inodes ressemble à des écritures « mystérieuses » alors qu’il reste des gigaoctets libres. - Répartissez la rétention : caches de build chauds (heures), artefacts Xcode tièdes (jours), journaux froids (semaines), avec un propriétaire explicite par arborescence.
- Les graphes Docker (ou équivalents) ajoutent des petits fichiers en overlay ; associez le pruning d’images à des contrôles d’inodes sur l’hôte, pas seulement à la taille des volumes.
- Dimensionnez les runners par rapport au SSD du forfait moins macOS, applications et marge ; visez environ 15 à 20 % de libre après la croissance hebdomadaire pessimiste.
df, les politiques de rotation des logs et la carte de vos caches CI.1. Où se cachent les octets et les inodes
Derived Data et SourcePackages dominent les charges Xcode interactives et CI : les builds incrémentaux sont rapides parce que les index restent. Sur des runners partagés sans racines éphémères par job, un changement de branche peut laisser des gigaoctets par espace de travail. Les caches Swift Package Manager et CocoaPods ajoutent une couche ; les arbres Pods sont réputés pour d’énormes nombres de fichiers même lorsque la taille totale reste modeste.
Les conteneurs dupliquent couches et métadonnées ; les bind mounts qui tirent node_modules ou des jeux de tests depuis l’hôte multiplient la pression sur les inodes du volume APFS sous-jacent. Le logging unifié (log show, DiagnosticReports, sorties standard archivées des jobs launchd) grossit discrètement tant que la rotation n’est pas réglée. Traitez chaque catégorie comme une ligne d’un tableur simple : pic attendu en Go, part d’inodes, âge maximal acceptable.
Les couches conteneurs et le cache BuildKit recoupent directement ce sujet — croisez ce modèle avec le Docker de production sur Mac cloud Apple Silicon : images arm64/amd64, bind mounts et cache de build — guide de dépannage (limites des forfaits) pour cadrer bind mounts, graphe local et budget SSD partagé avec Xcode.
2. Alertes façon quota avant les pages « disque plein »
Alertez sur le pourcentage d’espace utilisé et sur le pourcentage d’inodes séparément. APFS évite souvent les falaises classiques de fragmentation, mais les services déraillent encore près du plein : instantanés, caches locaux Time Machine et répertoires temporaires CI se disputent la dernière marge. Ajoutez une alerte sur la dérivée de croissance : si la croissance glissante sur sept jours dépasse la marge de manœuvre de votre palier, prévenez tôt.
Utilisez le même canal que pour les échecs de build ; les blocages disque ressemblent à des tests flaky. Indiquez quel système de fichiers le job touche — graphe conteneur contre /Users sur l’hôte — pour éviter de purger la mauvaise couche en incident.
# Instantané hôte rapide (à intégrer aux health checks)
df -h /
df -ih /
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
docker system df 2>/dev/null || true3. Échelle de nettoyage par paliers
Palier 0 — sûr à l’heure : tronquer les journaux CI connus pour leur taille, supprimer les workspaces de jobs échoués plus vieux que N heures, évincer les entrées de cache de build conteneur avec TTL d’âge explicite.
Palier 1 — quotidien : supprimer les images Docker pendantes et les conteneurs arrêtés ; purger les dossiers Derived Data par PR liés à des fusions fermées ; faire tourner les logs unifiés selon votre politique de rétention.
Palier 2 — hebdomadaire : reconstruire les caches froids à partir des fichiers de verrouillage après sauvegarde des secrets ; compacter les caches SPM si les contrôles d’intégrité passent ; auditer les bind mounts pour des copies accidentelles de .git ou DerivedData sur l’hôte.
Palier 3 — bris de vitre : retirer en masse d’anciennes données Xcode et caches globaux uniquement avec fenêtre de maintenance et vérification de builds reproductibles. Documentez ce qui a été supprimé — les auditeurs demandent.
Les pipelines de signature et de notarisation accumulent aussi des artefacts ; alignez la politique de cache avec CI iOS/macOS sur Mac cloud Apple Silicon : codesign, Notarization, stapler et frontières du trousseau — pipelines reproductibles et tableau de codes de rejet pour que les bundles d’export intermédiaires ne deviennent pas des ancres silencieuses sur le disque.
4. Frontières des forfaits et marge SSD
Les paliers publics kvmboot s’articulent autour de 16 Go de mémoire unifiée + 256 Go SSD et 24 Go + 512 Go (voir forfaits et fiches techniques). Budgétisez d’abord macOS, Xcode, Docker Desktop ou équivalent, agents de supervision et deux semaines de journaux ; attribuez le reste aux caches CI et aux magasins éphémères par runner. Si des jobs simultanés culminent pendant les trains de release, modélisez le chevauchement pessimiste — deux grosses archives iOS plus un build backend conteneurisé peuvent faire picorer RAM et disque transitoire avant que le nettoyage ne passe.
Gardez environ 15 à 20 % libres après ce scénario. Passer sous ~10 % invite à des timeouts mystérieux dans les compilateurs, les lanceurs de tests et les gestionnaires de paquets, coûteux à diagnostiquer sous pression d’incident.
5. Symptôme — cause — action
| Symptôme | Cause racine probable | Action privilégiée |
|---|---|---|
« No space left on device » mais df -h montre des Go libres |
Saturation d’inodes ou quota sur un volume imbriqué | Lancer df -ih ; purger les arbres « beaucoup de petits fichiers » (Pods, overlays, vieux logs) |
| CI plus lente après plusieurs builds verts | Caches grossis ; points chauds de métadonnées APFS | Limiter dans le temps le Derived Data ; purger le cache builder Docker ; vérifier les bind mounts |
| Alertes disque sur un seul runner | Dérive par hôte : artefacts de debug manuels | Comparer les sommes du en tête d’arborescence ; ré-imager ou imposer un script « concierge » |
6. Conclusion
La gouvernance disque sur des runners Mac cloud n’est pas un unique cron : c’est un modèle de capacité qui relie caches Xcode, conteneurs, journaux et SSD du forfait avec une conscience des inodes. Révisez le modèle lors d’un changement de version majeure de Xcode, de l’activation de nouveaux jobs parallèles ou de l’ajout de sidecars Dockerisés ; chaque bascule déplace à la fois la courbe des octets et celle du nombre de fichiers.
Sur Mac mini cloud, un SSD prévisible fait tenir la politique runner
La mémoire unifiée Apple Silicon limite le swap agressif quand se chevauchent compilations légères et agents de supervision. macOS offre une boîte à outils Unix mature — df, log, launchd et les chemins Xcode natifs — donc les runbooks disque se lisent pareil sur bare metal et dans le cloud. Des Mac cloud dédiés isolent votre courbe d’inodes du bruit des voisins par rapport aux pools partagés surchargés, tandis que la consommation au repos des puces M reste basse pour des tâches d’hygiène 7 × 24. Gatekeeper et SIP réduisent le risque d’altération par rapport à des hôtes Windows CI improvisés, et le coût total de possession bat souvent l’assemblage de Mac mini à bricoler, racker, patcher et surveiller vous-même.
Si vous voulez des runners Apple Silicon stables avec des paliers SSD clairs pour la CI et le build distant, le Mac mini M4 cloud kvmboot est un point de départ pratique — consultez les forfaits et tarifs pour garder Derived Data, conteneurs et journaux dans un budget que vous pouvez alerter au lieu de le découvrir à 2 h du matin.