2026 Files de build Mac cloud : parallélisme, DerivedData et marge disque pour un xcodebuild stable

Après migration iOS/macOS CI vers Mac cloud, les équipes documentent d'abord signature et profils—mais jobs parallèles, DerivedData hors contrôle et disques pleins provoquent des échecs intermittents bien avant la signature. Ce guide Xcode 26 détaille trois classes de pannes liées aux ressources, un tableau parallélisme/RAM, cinq étapes ou plus avec script df prêt à coller, plus une FAQ pour placer file d'attente et politique disque au même niveau d'observabilité que les certificats.

1. Pourquoi file et disque partagent le Runbook avec la signature

Sur Linux VPS on surveille CPU et profondeur de file ; sur macOS, Xcode et Swift écrivent d'énormes intermédiaires dans DerivedData, caches de modules et SourcePackages—débit disque et espace libre rivalisent avec le CPU. Après la checklist signing headless et le guide branchement CI/CD, vient la contention des ressources. Sans règles explicites, les builds « verts au second essai » sapent la confiance.

Archives parallèles se battent pour la RAM et le scratch du linker : plusieurs xcodebuild archive dépassent souvent les estimations mémoire ; le link remplit /tmp de gigaoctets. Un volume plein donne rarement un message « disque plein » clair de clang/ld.
DerivedData croît de façon monotone : le chemin par défaut ~/Library/Developer/Xcode/DerivedData grossit à chaque branche/schéma. Sans nettoyage par job, le volume système tombe sous 5 % libre et macOS déclenche ménage + jitter de compilation.
Sans métriques disque on croit à un problème réseau : les retries Swift Package ressemblent au CDN, mais un cache non inscriptible produit des logs similaires. Placez df et la taille DerivedData sur le même tableau de bord que la latence de file.

Pratique 2026 : mêmes règles de signature, parallélisme max, racines DerivedData par job et seuils disque avant/après build dans un seul modèle de pipeline. Le tableau ci-dessous donne des ordres de grandeur—affinez avec xcodebuild -showBuildSettings et vos métriques CI.

2. Parallélisme par nœud vs RAM et CPU

Matrice pour des SKU cloud M4 / M4 Pro typiques. Principe : limitez les archives simultanées à une ou deux sans mesure de pic linker ; montez davantage pour compile/test. Gardez ~15 % libre pour logs et snapshots.

SKU (exemple)	Archives parallèles suggérées	Plafond compile/test	Stratégie DerivedData	Cible espace libre
16 Go RAM / ≤10 cœurs	1	2 (selon projet)	Sous-dossier par job ou wipe nocturne	≥20 % libre
24–36 Go RAM	1–2	3–4	Espaces de noms branche + nettoyage hebdo	≥15 % libre
48 Go+ mémoire unifiée	2–3 (mesurer linker)	4–6	Cache à niveaux : derniers N commits	≥15 % libre ; volume de données idéal

Labels Jenkins ou runners self-hosted : verrou pour éviter deux archives partageant la même DERIVED_DATA_PATH sous un login—sinon locks de cache module et erreurs « fichier modifié ». Croisez avec le guide RAM et configuration lors du dimensionnement.

3. DerivedData, cache SPM et seuils disque (5+ étapes)

Automatisez aux mêmes points d'entrée SSH que le playbook migration Linux vers Mac.

Chemin DerivedData dédié par job : ex. export DERIVED_DATA_PATH="$WORK/DerivedData/$BUILD_ID" et -derivedDataPath systématique sur xcodebuild.
Échec rapide si disque bas avant trente minutes de compilation—extrait ci-dessous.
Politique de cache SPM versionnée : ~/Library/Caches/org.swift.swiftpm prévisible ; purge complète après grosses montées de Xcode.
Recycler après succès/échec : garder les K derniers DerivedData pour l'incrémental ; supprimer tout de suite les dossiers de jobs en échec ; balayage nocturne >7 jours.
COMPILER_INDEX_STORE_ENABLE=NO pour CI pure si pas d'index IDE—réduit fortement l'IO. Index uniquement sur pipelines d'analyse.
(Extra) Métriques : journaliser df -h et du -sh ; envoyer gros .ipa/.xcarchive vers stockage objet puis supprimer localement.

# Avant build : code de sortie non nul si espace libre < 12 % (adapter le montage)
AVAIL=$(df -h / | awk 'NR==2 {gsub(/%/,"",$5); print 100-$5}')
THRESH=12
if [ "${AVAIL%%.*}" -lt "$THRESH" ]; then
  echo "Espace libre sous ${THRESH}% — nettoyer DerivedData ou agrandir le volume"; exit 1
fi

                Astuce : mélanger Xcode interactif et CI headless sous le même utilisateur macOS entre en conflit sur DerivedData par défaut. Préférez un compte CI dédié ou des nœuds cloud séparés—comme pour l'utilisateur signing.
            

4. Faits techniques et paramètres citables

Pour audits internes : ① xcodebuild -derivedDataPath est le levier principal d'isolation parallèle. ② SPM peut journaliser des retries réseau alors que le cache n'est pas inscriptible. ③ APFS sous ~5–10 % libre peut déclencher snapshots locaux et builds à longue traîne. ④ ObjC/Swift peut exiger près du double de RAM au link qu'au pic de compilation—plus de cœurs n'implique pas plus d'archives parallèles. ⑤ Monter les artefacts sur un second volume réduit l'usure du volume système.

5. Des Macs de fortune à une base de build scalable

Quatre archives sur un Mac perso sous-dimensionné « marchent » jusqu'à ce que le disque soit plein, les échecs non reproductibles et une coupure bloque la release. Le seul bureau à distance résiste mal à une politique de file versionnée et s'accorde mal aux nœuds provisionnés par API.

En ancrant la file sur des Mac cloud élastiques à paliers RAM/disque prévisibles, avec automation SSH et marge pour remplacer les builders, vous gérez les caches comme sur des runners Linux tout en gardant la chaîne Xcode complète. Pour Xcode 26, maîtriser DerivedData et remplacer les nœuds disque défaillants, louer la capacité M4 Mac cloud VPSMAC est souvent plus prévisible qu'une machine fragile surchargée : vous codez parallélisme et nettoyage, la plateforme fournit compute et stockage de base, et les trains de release meurent moins souvent d'un « disque plein » mystérieux le vendredi.

6. FAQ

Partager un DerivedData pour accélérer l'incrémental ?

Jobs séquentiels sur une branche : oui. Archives parallèles : répertoires séparés pour éviter locks et caches corrompus. Lien symbolique vers cache distant possible.

Supprimer agressivement DerivedData ralentit-il chaque build ?

Les builds à froid coûtent plus cher mais sont planifiables—souvent mieux que des échecs aléatoires sur disque plein. Atténuer avec caches binaires ou quelques arbres conservés.

Mac cloud vs grappe Mac mini on-prem ?

On-prem : alimentation, baie, remplacement disques ; cloud : parallélisme de burst plus simple. Voir louer vs acheter ROI.