Le moyen le plus rapide de saboter le débit de la CI Apple Silicon est de nommer les caches d’après les branches Git. Les clés de branche réutilisent des graphes entre des commits qui modifient discrètement Package.resolved, Podfile.lock ou Gemfile.lock, produisant des rouges « aléatoires » et pire—des verts fantômes. En 2026, traitez les caches de dépendances comme du stockage adressé par contenu : hachez les lockfiles, épinglez le numéro de build de la toolchain et publiez la politique pour que chaque ingénieur comprenne qu’un miss de cache est sain.
Contexte opérationnel : rétention disque et artefacts, worktrees vs clones propres et affinité des runners. Pour des hôtes Mac mini M4 plus isolés à Hong Kong, au Japon, en Corée, à Singapour ou aux États-Unis, comparez les tarifs et suivez l’aide pour les modèles d’accès SSH/VNC.
Pourquoi les hachages de lockfile battent les étiquettes de branche
Les étiquettes de branche suggèrent que tout sur une ligne de développement partage l’état. Les graphes de dépendances ne suivent pas des lignes—ils suivent des résolutions exactes. Une seule fusion peut faire monter une version transitive sans toucher le code applicatif, invalidant des binaires tout en laissant le nom de branche inchangé. Hacher les lockfiles fait du hit de cache une obligation de preuve : si le hachage correspond, vous avez la preuve que la sortie du résolveur est identique modulo toolchain.
- Reproductibilité : les auditeurs peuvent corréler un build vert avec un digest de lockfile précis.
- PR parallèles : deux pull requests sur le même nom de branche (workflows fork) ne se heurtent plus silencieusement.
- Économie disque : un LRU sur les hachages limite mieux la croissance que « supprimer tout le dossier de branche ».
Matrice A : recette de clé par écosystème
| Écosystème | Entrées de verrouillage | Suffixe de chemin suggéré |
|---|---|---|
| SwiftPM + Xcode | Package.resolved + build Xcode |
spm/<sha256(resolved)>/xc<build> |
| CocoaPods | Podfile.lock + fichier de version Ruby |
pods/<sha256(lock)>/ruby<ver> |
| Bundler | Gemfile.lock |
bundle/<sha256(lock)> |
| npm / pnpm | package-lock.json ou pnpm-lock.yaml |
js/<sha256(lock)>/node<major> |
Matrice B : quand les caches partagés restent dangereux
Même un hachage de lockfile parfait ne vous sauve pas si des scripts post-install s’exécutent pendant la restauration. Traitez ces jobs comme un chemin froid sauf si vous sandboxez l’exécution des scripts et vérifiez les sommes des artefacts restaurés.
| Signal | Politique | Atténuation |
|---|---|---|
Hooks post_install modifiant les Pods |
Ne pas partager la restauration entre jobs | Exécuter les hooks à chaque build ; ne mettre en cache que les blobs téléchargés |
| Pods binaires sans vérification de somme | Traiter comme entrée non fiable | Vendoring avec hachages de contenu signés dans le dépôt |
| Builds de PR forkées | Espace de noms de cache séparé | Ne jamais réutiliser les chemins de cache du monorepo interne |
Valeurs numériques qui survivent aux audits
- Algorithme de hachage : SHA-256 des octets de lockfile normalisés (uniformisez CR/LF en CI).
- Largeur LRU : conservez les 12 derniers hachages par écosystème et par hôte.
- Âge max : évincez les hachages sans accès après 14 jours quel que soit le LRU.
- Alertes : pagez lorsque le volume de cache dépasse 70 % du disque CI dédié.
Note sécurité : les caches font partie de votre chaîne d’approvisionnement. Si un lockfile compromis peut empoisonner un cache tarball partagé, préférez un téléchargement éphémère + vérification à une réutilisation aveugle.
Huit étapes de déploiement
- Inventoriez les dépôts sans lockfiles commités—bloquez la mise en cache tant qu’ils n’existent pas.
- Émettez un digest comme artefact CI pour chaque build pour corrélation ultérieure.
- Montez les caches sur des volumes APFS rapides, pas sur des partages réseau, pour la résolution SPM.
- Câblez des métriques : taux de hit, secondes de restauration, comptes d’éviction.
- Documentez les attentes de cache froid dans CONTRIBUTING.md.
- Testez explicitement les workflows fork—espacez les caches par niveau de confiance.
- Associez à la politique de checkout du guide worktree pour éviter le double partage.
- Mettez à l’échelle le matériel lorsque les évictions saturent—NodeMac ajoute des nœuds M4 dédiés par région sans délais d’approvisionnement.
FAQ
Pourquoi les caches nommés par branche causent des verts fantômes ?
Ils réutilisent des binaires entre changements de lockfile. Hachez les lockfiles pour que les hits impliquent une sortie de résolveur identique.
SPM et DerivedData partagent-ils des clés ?
Non—séparez les préoccupations. Les clés SPM concernent la résolution ; DerivedData concerne les index de compilation et doit inclure des dimensions job ou toolchain.
À quelle fréquence élaguer ?
LRU dans une limite plus éviction par âge max ; toujours lié aux alarmes disque.