La stratégie de checkout est le multiplicateur silencieux derrière chaque pipeline macOS : le même Mac mini M4 peut sembler « assez rapide » avec git worktree ou « mystérieusement flaky » lorsque DerivedData fuit entre les jobs. En 2026, les équipes qui publient une politique explicite worktree vs clone propre réduisent le temps de file et le risque d’audit. Ce guide offre deux matrices, des budgets disque chiffrés, huit étapes de déploiement et des données structurées FAQ pour vos runbooks internes.
Associez cette politique à rétention disque et artefacts, enveloppes de capacité et règles d’affinité runner. Pour des hôtes dédiés supplémentaires à Hong Kong, au Japon, en Corée, à Singapour ou aux États-Unis, commencez par les tarifs et gardez l’aide ouverte pour les schémas d’accès SSH/VNC.
Pourquoi le mode de checkout est un problème d’ordonnancement, pas seulement du trivia Git
Les runners macOS auto-hébergés sont stateful par défaut : caches globaux, éléments de trousseau au niveau utilisateur, et l’emplacement DerivedData par défaut de Xcode survivent aux jobs sauf clôture. Un clone propre par job isole les objets Git mais pas automatiquement les compilateurs. Les worktrees partagent une base d’objets unique — rapide — mais amplifient toute erreur dans les scripts de nettoyage. Traitez le mode de checkout comme partie de votre récit de rayon d’explosion aux côtés des secrets et des identités de signature.
- Worktrees minimisent les octets
git fetchlorsque de nombreuses branches construisent le même flux de révisions. - Clones propres maximisent l’isolation lorsque des hooks post-checkout mutent l’outiling hors arbre.
- Les motifs hybrides (miroir nu chaud + worktrees éphémères) sont courants à l’échelle mais exigent des conventions de chemin strictes.
Matrice de décision A : choisir worktree, clone propre ou hybride
| Signal dépôt | Mode recommandé | Point de vigilance |
|---|---|---|
| Monorepo, fort churn, Xcode partagé | Hybride (miroir nu + worktrees) | Épingler DerivedData avec -derivedDataPath par worktree |
| Petite app, peu de dépendances, besoin de reproductibilité | Clone propre par job | Surveiller la bande LFS ; mettre en cache les blobs sur l’hôte avec vérification de checksum |
| Signature release avec identités liées au matériel | Hôte dédié + clone propre | Ne jamais partager une base worktree avec des forks non fiables |
| Builds PR forkées de contributeurs externes | Clone éphémère sur chemin unique | Désactiver les miroirs nus partagés au-delà des frontières de confiance |
Matrice de décision B : placement du cache vs risque de fuite
Le mode de checkout choisit où vivent les objets Git ; le placement du cache choisit ce qui survit au prochain job. Sans aligner les deux, vous « clonez propre » tout en fuyant encore l’état du compilateur via des chemins globaux.
| Cache | Défaut sûr sur runners M4 | Symptôme de fuite |
|---|---|---|
| Swift Package Manager | SourcePackages par job sous temp d’espace de travail |
Dérive de version entre PRs si cache global réutilisé sans hash de lockfile |
| CocoaPods / Bundler | Vendor dans le clone ou cache tarball adressé par contenu | Extensions natives avec mauvais drapeaux d’architecture |
| Xcode DerivedData | Toujours scoper le chemin par ID de job | Tests UI instables après index partiel d’une autre branche |
Budgets disque exécutables (points de départ)
- Plafond miroir nu : garder les miroirs monorepo sous 120 GB sur hôtes 512 GB ; élaguer avec scripts audités, pas suppressions manuelles.
- Worktrees concurrents : plafonner à 4 par hôte sauf métriques IO montrant de la marge de débit lecture soutenu.
- Scratch clone propre : réserver 2× le plus grand arbre de travail attendu pour
git clone --depth 1plus pics LFS. - Alarme : pager quand l’espace libre du volume CI passe sous 15 % plus de 5 minutes.
Note d’audit : documentez à quel niveau de confiance appartient chaque groupe de runners. Une base worktree ayant déjà checkouté une PR forkée ne doit pas plus tard construire des artefacts release signés sans wipe documenté.
Huit étapes de déploiement
- Classer les dépôts en niveaux internes de confiance, partenaires et forks publics.
- Mesurer le p95 checkout+compile par niveau sous les deux modes pendant un sprint.
- Implémenter des conventions de chemin telles que
/ci/jobs/<id>/treeexclusivement possédées par l’automatisation. - Câbler des hooks post-job qui retirent worktrees, DerivedData et caches simulateur liés à l’ID de job.
- Bloquer les caches globaux sauf clé par hash de contenu + niveau de confiance.
- Ajouter des métriques pour secondes de checkout, mégaoctets LFS et pourcentage disque libre par hôte.
- Game-day un scénario disque plein deux fois par trimestre.
- Scaler le matériel lorsque le budget force un partage risqué — NodeMac peut ajouter des nœuds Mac mini M4 dédiés par région sans délais de colocation.
FAQ
Quand git worktree est-il sûr sur des hôtes Mac mini M4 CI partagés ?
Lorsque chaque chemin worktree est isolé par job, les hooks sont contrôlés, les sous-modules figés, et le nettoyage supprime le worktree et les caches colocalisés. Ne partagez pas un dépôt nu avec des sessions développeur interactives.
Pourquoi les clones propres échouent-ils encore aléatoirement ?
Souvent caches globaux, problèmes réseau LFS ou scanners touchant les sorties. Scoper les caches par job et corréler les échecs aux graphes réseau.
Combien de disque en plus pour des worktrees parallèles ?
Budgétez un arbre de travail plus le magasin d’objets partagé par worktree concurrent, plus DerivedData par job si vous compilez des projets Xcode.