2026 — CI Mac : caches Bazel et Gradle distants, repository_cache, disk_cache et NVMe

Un même runner Mac CI qui mélange Bazel, Gradle et plusieurs xcodebuild bute d'abord sur les E/S NVMe, pas sur le CPU. Les blobs (repository_cache Bazel, dépôts Gradle) et les caches d'actions (disk_cache Bazel, build cache Gradle) ne doivent pas se battre sur un volume unique sans règles. Cette FAQ pose les partitions NVMe, le distant lecture seule et les plafonds de parallélisme sur nœuds « très rapides », en supposant un réseau stable et des identités machine déjà normalisées (JDK, Xcode). Pour le pool global (cloud, auto-hébergé, quotas), voir 2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ? ; pour DerivedData, SwiftPM et la concurrence xcodebuild elle-même, enchaînez avec 2026 — Builds Mac parallèles multi-dépôts : chemins DerivedData fixes, clés de cache SwiftPM, pics disque de xcodebuild concurrent et nettoyage — FAQ pool d'entreprise.

1. Bazel et Gradle : deux philosophies de cache distant

Bazel reste contenu-adressable (actions, métadonnées, blobs courts) ; Gradle gonfle vite le build cache et les dépôts de dépendances avec de grosses archives. TLS, authentification et pools de connexions s'imposent des deux côtés, mais le profil réseau diffère : allers-retours CAS versus transferts séquentiels. Sur Mac CI, privilégiez un chemin à faible RTT et, si possible, une route « build » séparée du trafic artefacts utilisateur.

Principe utile : exposer un cache distant partagé en lecture seule pour la majorité des pipelines, et réserver quelques identités ou agrégateurs pour l'écriture, simplifie l'audit en cas de suspicion de mauvaise entrée en cache.

2. repository_cache et disk_cache : pourquoi les séparer sur NVMe

Le repository_cache écrit de gros blobs ; le disk_cache Bazel éparpille de nombreux petits fichiers quand le graphe bouge. Sur un volume APFS unique, fsync, journal et archives Gradle se gênent. Montez deux NVMe distincts (ou partitions à quotas et GC décalés) : dépendances lentes d'un côté, caches d'action volatiles de l'autre. Isolez aussi -derivedDataPath et le home Gradle pour éviter qu'un xcodebuild ne fasse évincer Bazel. Décalez les fenêtres de GC : deux nettoyages simultanés sur un même contrôleur tuent les IOPS perçues.

3. Multi-jobs sur une machine : xcodebuild en parallèle et files d'attente réelles

Plusieurs xcodebuild mangent la RAM (simulateurs, index, liaison) puis le disque. Si Bazel et Gradle lisent le même NVMe que Xcode, un bon taux de hit peut quand même allonger le mur horaire : les files s'allongent au-delà du sweet spot du contrôleur. Fixez d'abord le nombre de xcodebuild par hôte, puis augmentez Gradle et Bazel en regardant l'attente disque, pas le CPU. Avec un distant lecture seule, gardez une partition de repli ou un proxy cache : sans écriture locale dédiée, une coupure réseau force des rebuilds complets sur le volume partagé.

  • Surveillez les métriques await et le pourcentage d'attente disque avant le CPU : un NVMe « libre » peut pourtant être saturé.
  • Étiquetez les images avec la version de Xcode et du JDK : les clés de cache qui dérivent rendent le distant inutile.
  • Réservez au moins l'espace d'un build froid complet par job pour les artefacts temporaires et les signatures.

4. FAQ pour les responsables plateforme

  • Faut-il imposer la lecture seule sur le distant ? Oui lorsque la reproductibilité des branches de production prime ; canalisez les écritures vers des rôles limités ou un agrégateur dédié.
  • Pourquoi le parallélisme stagne sur un nœud NVMe haut de gamme ? Souvent à cause des IOPS métadonnées et des verrous applicatifs, pas du débit séquentiel ; envisagez le sharding ou plusieurs endpoints cache.
  • Risque de colocaliser Bazel et Gradle sur un seul disque ? Les cycles de GC se superposent ; séparez physiquement ou décalez les fenêtres de maintenance.
  • Quand isoler les runners Apple ? Lorsque la charge mixte Android / backend noie la latence perçue par Xcode — la séparation matérielle reste l'argument le plus simple auprès des parties prenantes.
  • Compilation Cache Xcode 26 à côté de Bazel : vérifiez que le service gRPC et les chemins DerivedData ne partagent pas le même volume que repository_cache sans quota, sinon les hits distants masquent une saturation locale.

Apple Silicon, macOS et Mac mini : valider vos partitions sur du matériel stable

Les partitions ne se valident bien que sur une pile homogène : macOS aligne Xcode et simulateurs ; Apple Silicon absorbe JVM et indexation Swift dans une mémoire unifière large. Gatekeeper, SIP et FileVault simplifient l'argumentaire sécurité. Un Mac mini peu gourmand convient aux pools qui gardent des caches chauds entre les vagues.

Pour figer vos mesures NVMe et vos plafonds, le Mac mini M4 reste un repère simple. Pour du Mac cloud dédié, la page d'accueil Macstripe permet de choisir région et configuration avant de mesurer la latence vers le cache — équipez votre labo d'un Mac mini M4 si vous voulez le même silicium qu'en production.