Sur un pool de runners Mac alimenté par des nœuds Apple Silicon très bien dotés en RAM, la question n'est plus « peut-on paralléliser ? » mais comment isoler les checkouts sans sacrifier la réutilisation des caches. Deux familles de solutions dominent : git worktree à partir d'un dépôt nu de référence, ou un clone propre par job (souvent shallow ou blobless). Les PR qui touchent plusieurs dépôts amplifient la pression réseau et disque ; pour le dimensionnement disque et les stratégies Git avancées, reliez cette FAQ à
2026 — Pool CI Mac entreprise : cache de compilation Xcode 26 face à la réutilisation DerivedData classique — jobs parallèles, service cache gRPC distant, montée en charge NVMe et invalidation des hits : FAQ de mise en œuvre
et, pour la contention quand plusieurs workers Xcode cohabitent, à
2026 — CI Mac d'entreprise : tests Xcode en parallèle et découpage des Test Plans — comment éviter la contention des simulateurs ? (nœuds haute mémoire, nombre de workers et seuils disque : FAQ).
1. Worktree partagé ou clone par job : que garantit-on à l'équipe release ?
Le clone par job offre la garantie la plus simple : chaque pipeline repart d'un répertoire vierge, sans état résiduel dans .git ni hooks locaux oubliés. Le coût est une charge disque et CPU répétée à chaque job, surtout si le dépôt est volumineux ou si vous récupérez l'historique complet. À l'inverse, git worktree add depuis un mirror local à jour réduit fortement le temps de préparation : Git réutilise les objets déjà présents et ne duplique que l'index de travail. La contrepartie est une discipline stricte : verrous sur le dépôt principal, politique de nettoyage des worktrees orphelins, et vigilance sur les scripts qui modifient la config Git globale du compte runner.
2. Latence de checkout quand plusieurs PR frappent plusieurs dépôts
Les pipelines multi-dépôts sérialisent rarement les fetch : un orchestrateur déclenche N checkouts quasi simultanés. Sur un hôte haute mémoire, le goulot devient vite I/O NVMe ou la bande passante vers le forge, pas le manque de RAM. Préférez un cache d'objets Git central (bare mirror + git clone --reference ou équivalent côté runner) plutôt que N clones complètement indépendants. Mesurez le P95 « début du job → premier xcodebuild utile » : c'est ce chiffre que les équipes produit retiennent, pas la durée brute de git fetch.
3. Pics disque : pourquoi la RAM généreuse n'absorbe pas tout
Apple Silicon combine une mémoire unifiée rapide avec des SSD NVMe performants, mais chaque clone matérialise toujours des fichiers réels sur APFS : modules SwiftPM extraits, caches d'outils, binaires intermédiaires. Quand trois PR parallèles déclenchent chacune un resolve de dépendances, le pic peut dépasser la somme « taille du dépôt × 3 » à cause des archives temporaires. Gardez un quota par job et une politique de LRU sur les répertoires de build ; surveillez l'espace libre avant la saturation des inode ou des snapshots Time Machine accidentels sur les machines de labo.
4. Réutiliser CocoaPods, npm, Gradle et DerivedData sans mélanger les PR
La réutilisation efficace impose de séparer la clé de cache (empreinte des fichiers de lock, version Xcode, architecture) du répertoire de travail du job. Un volume NVMe partagé en lecture seule pour les artefacts téléchargés, plus un overlay ou un bind-mount en écriture par job, limite les copies tout en évitant les collisions. Pour Xcode, harmonisez DERIVED_DATA_PATH avec la politique décrite dans la FAQ cache ci-dessus ; pour les gestionnaires de paquets, centralisez le store (PODS_CACHE_DIR, cache npm global contrôlé, etc.) mais isolez les résolutions concurrentes derrière un mutex léger côté runner.
5. Tableau comparatif synthétique
| Critère | Worktree depuis mirror | Clone par job |
|---|---|---|
| Latence checkout | Très basse une fois le mirror chaud | Plus élevée ; shallow/blobless atténue |
| Pic disque | Modéré si worktrees purgés | Souvent plus haut en parallèle |
| Isolation PR | Bonne si un worktree = une PR | Maximale par construction |
| Cache dépendances | Excellente si clés stables | Excellente avec store partagé RO |
6. FAQ synthétique
- Peut-on mixer worktrees et clones sur un même hôte ? Oui, à condition de taguer les chemins et d'éviter que deux jobs écrivent dans le même
DEPENDENCIES_ROOT. - La haute RAM compense-t-elle un petit SSD ? Non durablement : sans purge, les clones successifs finissent par saturer le volume quel que soit le silicium.
- Faut-il un compte système par stratégie ? Souvent utile pour séparer les caches Trousseau et les hooks Git entre pipelines critiques et expérimentaux.
- Comment valider avant production ? Rejeu d'une journée de traces réelle avec la concurrence PR cible et mesure du P95 checkout + espace libre minimum observé.
Apple Silicon, macOS et Mac mini : mesurer sur du matériel représentatif
Les compromis worktree / clone ne se jugent pas sur papier : il faut un nœud bare metal proche de votre forge, avec la même génération de puce et la même taille de RAM que la production. macOS reste la plateforme de référence pour xcodebuild, les simulateurs et la signature ; les mécanismes Gatekeeper, SIP et FileVault simplifient l'argumentaire sécurité auprès des équipes IT. Un Mac mini silencieux et sobre sert d'excellent banc d'essai pour rejouer les scénarios multi-dépôts avant de généraliser une stratégie de cache sur tout le pool.
Le Mac mini M4 combine performance, silence et faible consommation en veille (de l'ordre de quelques watts), ce qui rend les campagnes de charge plus abordables qu'avec des stations bruyantes. Si vous voulez aligner labo et production sur du matériel dédié dans le cloud, la page d'accueil Macstripe permet de choisir région et configuration ; pour industrialiser la même recette que dans cet article, le Mac mini M4 reste aujourd'hui l'un des meilleurs compromis entre coût total de possession, bande passante mémoire et stabilité des builds iOS.
