Public : équipes qui exécutent la CI sur Mac distants en APAC et aux États-Unis, après application du runbook Git et registre Docker (retries), mais qui consacrent encore des dizaines de minutes au transfert d’objets et aux matrices monorepo complètes avant le premier appel compilateur. Résultat : conserver le réglage des liens dans le runbook retries ; employer clones partiels (sans blobs / sans arbres), checkout clairsemé et détection de changements pour réduire l’arbre de travail et le graphe de build, afin que les minutes M4/M4 Pro servent aux compilateurs, pas à l’exploration d’arbres hors scope. Structure : six idées reçues, matrice de stratégie, extraits de commandes, runbook en six étapes, trois métriques tableau de bord, clôture opérationnelle.
Apple Silicon augmente le plafond de calcul, mais les monorepos butent souvent sur la matérialisation des objets et l’indexation de l’espace de travail : un job unique peut télécharger un graphe de commits volumineux, déployer des milliers de répertoires, puis lancer des outils de build qui, par défaut, parcourent l’intégralité du dépôt. Le réglage inter-régions raccourcit les traînes par transfert mais ne supprime pas le gaspillage lié aux objets jamais nécessaires. Voici six lectures erronées récurrentes issues de la traque en production.
--depth=1 comme universel : l’historique superficiel aide, mais les arbres et les blobs lourds peuvent encore entrer dans l’espace de travail sur les chemins par défaut ; si le point d’entrée du build parcourt tout le dépôt, les processeurs restent inactifs sur l’analyse de configurations sans rapport.--filter=blob:none (sans blobs) et --filter=tree:0 (sans arbres) interagissent différemment avec le checkout, les cônes clairsemées et Git LFS ; mélanger les modes sans documenter les récupérations à la demande crée des pics cachés sur les builders distants..git : sur des hôtes 1 To/2 To, la croissance de .git plus les caches superposés peut épuiser le disque avant compilation ; rattachez les seuils à la même revue stockage que le guide multi-régions et conditions de location.Combinez ces leviers avec le guide exécuteurs auto-hébergés : les runners décident quelle machine prend un job, le runbook retries stabilise les pulls, cet article définit combien récupérer et compiler—livrez les trois dans un même dossier de revue.
Choisissez les commandes selon la forme du dépôt, la tolérance aux récupérations à la demande et les exigences de reproductibilité hors ligne—non selon l’habitude individuelle—lors des revues de conception pipeline.
| Stratégie | Idéal pour | Gain principal | Risque / coût |
|---|---|---|---|
| Clone complet + arbre complet | Petits dépôts, reproductibilité hors ligne stricte, premiers audits | Comportement le plus simple, traque la plus courte | Transfert d’objets et E/S espace de travail élevés sur grands monorepos inter-régions |
Sans blobs (--filter=blob:none) | Historique profond, CI ne nécessite que l’arbre courant | Réduction majeure du téléchargement initial de blobs ; s’associe aux clones superficiels | Récupérations de blobs à la demande pendant checkout/build ; surveiller le débit de fetch à la demande |
Sans arbres (--filter=tree:0) | Arbres extrêmement volumineux, vues mono-commit | Report de la matérialisation des arbres | Compatibilité toolchain à valider ; complexité de traque plus élevée |
| Checkout clairsemé (cône) | Monorepos multi-applications à frontières de sous-arbres claires | Moindre pression E/S et sur l’index ; jobs parallèles avec cônes distincts | Cônes mal configurés : fichiers manquants silencieux ; versionner et revoir les cônes |
| Détection de changements + matrice minimale | Graphes npm/yarn/pnpm, Gradle, style Bazel | Limite le graphe de compilation aux fermetures affectées | Maintenir cartes de chemins et règles de base ; canaris pour détecter les oublis |
Remplacez les chemins par vos racines monorepo. Validez le mode sans arbres sur un job canari avant déploiement fleet. Conservez GIT_HTTP_LOW_SPEED_* du runbook inter-régions pour plafonner la latence de traîne lors des récupérations à la demande.
# 1) Blobless + shallow + single branch (common CI baseline)
git clone --filter=blob:none --depth=1 --single-branch \
--branch "${BRANCH}" "https://example.com/org/monorepo.git" repo
cd repo
# 2) Sparse cone: store the list in git and require CODEOWNERS review
git sparse-checkout init --cone
git sparse-checkout set apps/ios libs/shared-contracts
# 3) Change detection sketch (implement via git diff, path prefixes, or tooling)
# BASE_SHA=$(git merge-base origin/main HEAD)
# git diff --name-only "$BASE_SHA"..HEAD | awk -F/ '{print $1"/"$2}' | sort -u
# 4) Avoid: enabling treeless globally without Xcode/SwiftPM canary jobs
Attention : après clones partiels et cônes clairsemés, les pointeurs LFS et binaires volumineux peuvent se trouver hors cône. Ajoutez les chemins ressources au cône ou utilisez des caches d’artefacts ; sinon vous obtiendrez des échecs « fichier manquant » en fin de pipeline ressemblant à de la flakiness des tests.
Supposez secrets et étiquettes runner déjà isolés. Si volumes de cache et droits sur .git ne sont pas séparés, corrigez d’abord avec les guides runner et build reproductible.
~/.gitconfig local..git, caches de build et DerivedData ; éviter plusieurs jobs partageant un même espace de travail lorsque les cônes diffèrent.Ces séries complètent les KPI de lien du runbook retries afin de distinguer stabilité des fetchs et engorgement de l’espace de travail.
Note terrain (ordre de grandeur, pas benchmark) : en 2025–2026, les monorepos comptant des dizaines de milliers de chemins consacrent souvent des dizaines de minutes uniquement à l’expansion de l’espace de travail avant compilation. Des cônes clairsemés revus et des matrices affectées augmentent en général la part du temps mural passée dans les compilateurs sur le même matériel—l’économie de location doit donc inclure la politique de checkout, pas seulement le palier CPU.
Les équipes qui laissent en permanence des builders loin de la région d’origine du Git corrigent rarement le gaspillage structurel par la seule bande passante ; coupler réglage des liens et politique de cônes/détection correspond à la façon dont les organisations colocalisent la CI macOS avec les dépôts primaires. Documentez les deux volets dans le même manuel d’exploitation pour éviter les boucles nocturnes « redémarrer le runner ».
Les scripts personnels et hôtes ponctuels manquent d’audit des changements de cône, de contrats de cache et de cohérence multi-régions : le clairsemage sparse de l’ingénieur A réussit en local tandis que la CI propre de l’ingénieur B échoue ; un changement de région invalide chemins de fetch et seuils disque. Une CI Apple Silicon de production requiert bare metal dédié, régions mondiales et mix location base-plus-pic avec politique Git, politique de checkout et coût sur une même page.
Des fournisseurs fragmentés sans egress prévisible et marge disque incitent aux « builds complets et plus de machines ». Les équipes qui ont besoin de frontières de répertoires reproductibles, montée en charge horizontale par région et modèles de secrets CI alignés sur la production se tournent en général vers des plateformes Mac cloud professionnelles plutôt que vers des hôtes temporaires en rotation. MACCOME propose des nœuds bare metal Mac mini M4 / M4 Pro à Singapour, au Japon, en Corée, à Hong Kong, US East et US West avec conditions flexibles afin d’aligner builders, dépôts et stratégie de cônes. Commencez par les tarifs publics Mac mini, puis confirmez les pages régionales.
Plan pilote : louer à court terme un builder aligné sur la région de votre dépôt principal, enchaîner deux cycles de revue de ce runbook, puis trancher mensualisation ou trimestre et passage éventuel à 2 To—éviter une facture récurrente « région peu chère + checkout monorepo complet ».
FAQ
Frontière avec le runbook Git/registre (retries) ?
Le runbook retries porte sur les paramètres de lien ; cet article porte sur le volume d’objets et la portée de l’espace de travail. Si les fetchs sont stables mais les jobs restent lents, ouvrez d’abord cette matrice. Confirmez la tarification sur les tarifs Mac mini avant commande.
Checkout clairsemé ou détection de changements en premier ?
En général les deux : le clairsemage réduit la pression par machine, la détection réduit la matrice. Si les cônes ne sont pas encore versionnés, resserrez d’abord les builds affectés pour limiter les échecs discrets de chemins manquants. Pour le flux opérationnel, voir le centre d’aide location Mac mini.
Le mode sans arbres est-il prêt pour la production ?
Canariser sur branches non release, journaliser le comportement des fetchs à la demande et coupler avec une validation Xcode/SwiftPM avant déploiement fleet.