--disk_cache, --remote_cache, --jobs, repository_cache), la coordination Git shallow, puis l’impact régional et du parallélisme. Pages sans login : accueil, liste du blog, stratégie cache Git & npm, SSH relais & accélération réseau.
① Bazel : sources externes et registres sur Mac distant — portrait des goulots
Sur un runner macOS partagé, la phase « fetch » mélange latence WAN, débit disque et concurrence de processus. Les rules http_archive, git_repository, go_repository ou les registres bazel_dep (bzlmod) déclenchent des rafales de petits fichiers : un proxy d’entreprise ou un RTT élevé vers l’extérieur se traduit par des timeouts qui ressemblent à des erreurs de build.
Symptômes typiques 2026 : (1) le disque NVMe monte à 85–95 % d’occupation et les écritures du cache se fragmentent ; (2) deux pipelines écrivent dans le même préfixe ~/.cache/bazel sans isolation ; (3) --jobs élevé multiplie les téléchargements simultanés et fait plafonner le nombre de sockets côté pare-feu ; (4) un miroir interne manquant force un repli vers des origines publiques encore plus lentes depuis votre région.
Pour les pipelines JVM voisins, reportez-vous au guide Gradle & Maven — caches et parallélisme : les mêmes lois de saturation réseau s’appliquent lorsque Bazel déclenche des résolveurs externes en parallèle.
② Cache disque local (--disk_cache) vs cache distant (--remote_cache) — tableau de seuils
Précision utile : --disk_cache met en cache les résultats d’actions (sorties de build). Les archives HTTP téléchargées par le mécanisme de dépôt externe profitent surtout de --repository_cache=chemin. --remote_cache partage ces résultats entre machines via gRPC/HTTP. Sur Mac distant, on combine souvent les trois couches : repository cache pour les sources, disk pour le runner, remote pour l’équipe.
| Critère | Disk + repository (local) | Remote cache (équipe) | Seuil indicatif |
|---|---|---|---|
| Taille du pool CI | Suffisant pour 1–2 runners séquentiels | Fort intérêt dès 3+ machines ou jobs concurrents | Passer au remote quand >40 % des builds répètent les mêmes actions |
| Liaison transfrontière | Réduit les re-téléchargements une fois hydraté | Réduit egress si le remote est proche du runner | Si le remote est sur un autre continent, ajoutez --remote_download_minimal (selon compatibilité) pour limiter le retour des blobs |
| Coût disque runner | Grand répertoire ; surveiller inodes | Déplace le stockage hors du Mac | Allouer ≥80 Go dédiés au couple disk+repository sur nœud partagé |
| Reproductibilité | Dépend du nettoyage et des hashes | Renforce l’alignement des clés d’action | Invalider le remote après changement de toolchain Xcode ou de flags host |
Décision rapide : pas de remote interne fiable ⇒ hydratez d’abord repository_cache + disk_cache sur SSD ; dès que plusieurs branches martèlent les mêmes cibles, un --remote_cache dans la même région que le runner amortit la bande passante transfrontière.
③ WORKSPACE / MODULE.bazel : échecs de tirage — retries, timeouts et liste de flags
Les erreurs « repository failed » sont souvent transitoires. Outre le retry côté orchestrateur (boucle 2 s / 4 s / 8 s, trois passes maximum), Bazel expose des leviers utiles en 2026 :
| Objectif | Flag / variable | Valeur de départ | Remarque |
|---|---|---|---|
| Retries téléchargeur | common --experimental_repository_downloader_retries=N |
3 à 5 |
À valider sur votre version ; combinez avec jitter côté shell si le proxy limite les rafales |
| Cache HTTP dépôts | build --repository_cache=… |
SSD local par job | Évite de re-télécharger http_archive après un échec réseau partiel |
| Isolement sorties | startup --output_user_root=… |
Chemin par CI_PIPELINE_ID |
Réduit les courses entre jobs sur un même hôte |
| Nettoyage ciblé | bazel clean --expunge |
Après rotation certificat / proxy | Coûteux ; préférer purge du repository cache incohérent avant l’expunge complet |
bzlmod : avec MODULE.bazel, surveillez les registres (registry.bazel.build ou miroir d’entreprise). Si votre Mac distant ne peut pas joindre le registre public, servez un fichier JSON de registre en interne ou figez les archives comme vous le feriez pour Maven (voir aussi Git & Docker — guide d’accélération pour la cohérence des miroirs).
④ Git clone partiel (shallow) et Bazel en parallèle — répertoires, quotas disque et FAQ
Règle d’ordonnancement : terminez git fetch / git checkout avant bazel fetch //... ou le premier bazel build. Sinon, Bazel et Git concurrencent le même volume : latence disque en cascade et risque de fichiers incomplets vus par les rules Git.
Shallow clone : --depth 1 accélère le checkout mais peut manquer des commits référencés par une rule externe (sous-modules, strip_prefix + tag ancien). En cas d’échec « unknown revision », élargissez avec git fetch --deepen=N ciblé plutôt que de désactiver shallow partout.
- Même SSD pour Git et Bazel ? Oui si le débit séquentiel reste >200 Mo/s en écriture soutenue ; sinon séparez
repository_cachesur un second volume. - Quota utilisateur bas sur macOS partagé ? Préfixez tous les caches par compte de service du runner et purgez les jobs >7 jours pour libérer inodes.
- LFS ? Exécutez
git lfs pullavant Bazel si les rules lisent des blobs LFS ; alignez-vous sur le guide sous-modules du blog si vous croisez LFS ethttp_archive.
⑤ Région du nœud Mac distant et compilation parallèle — impact sur la stabilité des tirages
Un nœud proche de votre registre binaire interne ou de votre remote_cache réduit le RTT et stabilise les gros uploads d’AC. À l’inverse, un runner « Mac distant » géographiquement éloigné mais proche de vos développeurs n’apporte rien si 80 % du temps passe sur des origines HTTP dans une autre région.
| Profil liaison | --jobs indicatif | Stratégie |
|---|---|---|
| WAN instable / proxy strict | HOST_CPUS*0.25 à 0.5 |
Prioriser repository_cache hydraté ; éviter //... massif en première étape |
| Lien datacenter régional stable | HOST_CPUS*0.5 à 1.0 |
Activer remote cache lecture/écriture ; surveiller la file d’upload |
| Builds entièrement locaux (deps vendues) | Plafond physique RAM/disque | Le goulot devient compilation ; monitorer pression mémoire Xcode si mix iOS |
Quand vous augmentez --jobs, chaque volet peut relancer des résolutions : gardez un plafond sur le nombre de pipelines concurrents par hôte (souvent 1–2 jobs lourds) pour ne pas transformer le Mac distant en amplificateur de rafales réseau. Pour une vision globale « achat vs location » du nœud, ouvrez le guide location vs achat de nœud CI.
Synthèse opérationnelle et prochaines étapes
- Afficher dans les journaux CI :
output_user_root,disk_cache,repository_cache, URLremote_cache. - Vérifier l’espace libre (>15 %) et les inodes ; planifier purge des préfixes de jobs terminés.
- Git shallow validé sur le commit exact attendu par
WORKSPACE/MODULE.bazel. - Backoff orchestrateur 2/4/8 s sur
bazel fetchaprès erreur réseau ; capturer les 30 dernières lignes dans l’artefact CI.
En bref : isolez les caches par job, hydratez repository_cache, n’activez le remote_cache distant qu’avec une région cohérente, et bornez --jobs sur WAN fragile. Pour passer en production sans friction, parcourez l’accueil MacPull, la page forfait / nœud Mac distant, les tarifs et le centre d’aide SSH & connexion — pages publiques, sans connexion obligatoire — puis prolongez avec les articles CI et réseau cités ci-dessus.
Poursuivre sur MacPull (sans login sur ces pages)
Réservez un nœud Apple Silicon pour vos pipelines Bazel, consultez les tarifs et ouvrez le centre d’aide pour la connexion SSH — puis enchaînez avec le blog CI pour optimiser tirages, caches et relais réseau.