Grenzüberschreitende CI auf Remote-Macs mit Bazel scheitert selten an der Compiler-CPU, sondern an Registry-Latenz, kleinteiligem Platten-IO (externe Repos, Aktions-Cache) und überzogener Parallelität. Dieser Leitfaden bündelt Schwellen für --disk_cache vs. --remote_cache, WORKSPACE/MODULE-Timeouts, Job-Parallelität und Git-Shallow neben Bazel. Vertiefung: Startseite, Technik-Blog, Mirror-Optimierung, Build-Pool & Platten-FAQ.

① Bazel-Externals & Registry: Engpassprofil auf Remote-Macs

Beim ersten bazel build //... dominieren drei Kostenblöcke: Netz-Downloads (http_archive, Maven/NPM über Rules, Bzlmod-Registries), IO auf der lokalen SSD (Entpacken, Symlinks, repository_cache) und Analyse/Graph. Auf geteilten Build-Macs verstärken sich diese Effekte, wenn mehrere Jobs gleichzeitig fetch-Phasen ausführen oder dieselbe Platte für Git-Objekte, output_user_root und Docker-Layer teilen.

  • Registry-RTT: Bzlmod-JSON und Archive hintereinander laden → lange kritische Pfadketten bei hoher Latenz.
  • Random-IO: Tausende kleiner Dateien in externen Repos erschöpfen IOPS schneller als sequenzielle Compiler-Ausgaben.
  • Lock-Konflikte: Gemeinsames output_base ohne Isolation führt zu blockierenden Server-Instanzen oder korrupten Locks.

Praxisregel: Externe Auflösung (bazel fetch / erste Analyse) separat messen; wenn sie >40 % der Kaltlaufzeit ausmacht, priorisieren Sie repository_cache, regionale Runner und WAN-Timeouts – nicht nur --jobs.

② Lokaler disk_cache vs. remote_cache: Schwellen-Tabelle

--disk_cache beschleunigt Aktions-Cache-Treffer auf derselben Maschine. --repository_cache (separate Option) puffert heruntergeladene externe Quellen. --remote_cache teilt Aktions-Artefakte im Team – wirkt erst nach stabilen Build-Keys und konsistenten Toolchains.

Kriterium Nur --disk_cache --remote_cache (+ optional disk)
Team-Trefferquote Nur lokal / Host Über Runner-Pool teilbar
Plattenbedarf Wächst mit Targets; pro Host planen Primär Netz + Server-Speicher
WAN-Last Gering nach Warm-up Abhängig von Cache-Nähe & TLS
Ops-Aufwand Nur Pfad & Quota Auth, TLS, GC, Zugriffskontrolle
Empfehlung Einzel-Runner, schnelle NVMe ≥2 geteilte Macs gleiche Flags/Toolchain

Kopierbare .bazelrc-Fragmente (Pfade anpassen):

# Pro CI-Job eigene Verzeichnisse (Beispiel) build --disk_cache=/var/tmp/bazel-disk/${CI_JOB_ID} build --repository_cache=/var/tmp/bazel-repo/${CI_JOB_ID} # Remote-Cache (gRPCS-Beispiel; Host/Zertifikat anpassen) build --remote_cache=grpcs://cache.intern.example:443 # Nur lesen, nichts hochladen (öffentliche/unsichere Runner) build --noremote_upload_local_results

Entfernen Sie --noremote_upload_local_results, wenn vertrauenswürdige Runner Ergebnisse in den gemeinsamen Cache schreiben sollen.

③ WORKSPACE / MODULE: Timeouts, Retries & Parameter-Checkliste

Ob klassisches WORKSPACE oder MODULE.bazel mit Registries: der Downloader nutzt gemeinsame HTTP-Stacks. Skalieren Sie Timeouts vor dem Eskalieren der Job-Parallelität.

Flag / Maßnahme Zweck Startwert (WAN / grenzüberschreitend)
common --http_timeout_scaling=… Multiplikator für HTTP-Timeouts im Downloader 2.0–4.0
CI-Wrapper Backoff Äußere Wiederholung bei transienten Fehlern max. 3 Läufe, Pause 2s / 4s / 8s
bazel fetch //… Externe Phase von Compile trennen Eigenes Pipeline-Stadium mit Artefakt-Cache
--output_base=… Isolation & reproduzierbare Locks Pro Job eindeutiger Pfad auf SSD
Registry-Mirror (Bzlmod) Redundanz & geringere RTT Firmen-Proxy oder regionales Mirror-JSON
common --http_timeout_scaling=3 # Beispiel: fetch vor dem eigentlichen Build bazel --output_base=/var/tmp/bazel-ob/$CI_JOB_ID fetch //... for d in 2 4 8; do bazel --output_base=/var/tmp/bazel-ob/$CI_JOB_ID build //targets:all && exit 0 sleep "$d" done exit 1

Bei 401/403 nicht blind wiederholen – Secrets und Registry-ACLs zuerst fixieren. sha256-Pins in http_archive beibehalten, damit gespiegelte Archive nicht stillschweigend driften.

④ Git-Shallow & Bazel: Verzeichnisse, IO-Quoten & FAQ

Die Pipeline-Arbeitskopie darf --depth 1 nutzen, solange alle für Bazel sichtbaren Dateien vorhanden sind. Externe git_repository-Regeln legt Bazel unter dem Ausgabebaum ab – dort greifen andere Quoten als im Projekt-.git.

Frage Empfehlung
Gleiche SSD für Git und Bazel? Ja, wenn NVMe; Pfade logisch trennen ($CI_PROJECT_DIR vs. output_user_root / repository_cache).
Platten-Warnschwelle Ab 85 % Belegung Cleanup-Jobs; Bazel-Caches rotieren oder Job-Prefix löschen.
Inode-Erschöpfung Externe Archive erzeugen viele kleine Dateien – df -i in CI loggen.
Shallow vs. feste Commits Immer exakte Commit-IDs oder Tags in Rules; keine schwebenden Branches für reproduzierbare CI.

Mehr zu parallelen Pulls und Runner-Pools: Git Submodule & LFS CI-Matrix.

⑤ Region des Remote-Mac-Knotens & parallele Builds: Stabilität der Pulls

Ein Runner in der Nähe Ihrer Artefakt-Quellen (Firmen-Registry, object storage, öffentliche CDN-Region) reduziert simultane TCP-Slow-Starts und Packet-Loss-Auswirkungen. Umgekehrt: hohe --jobs-Werte auf einem Host multiplizieren gleichzeitige HTTP-Verbindungen und können Proxy-Rate-Limits auslösen – sichtbar als sporadische timeout- oder reset-Fehler ohne Codeänderung.

Szenario --jobs-Start Erwarteter Effekt
Geteilter Mac, schmaler WAN-Uplink 2–4 Weniger konkurrierende Downloads; stabilere Metriken
Dedizierter Mac, starker Remote-Cache-Treffer auto oder ≤ Kernzahl CPU wird limitierend; WAN entlastet
Viele kleine externe Repos, kein repository_cache niedrig + fetch-Stufe Verhindert Download-Stürme im Link-Step

Für SSH-/Proxy-Beschleunigung zum Runner: SSH-Relay & Proxy.

Kurz-FAQ (Build-Alltag)

Remote-Cache-Hits, aber langsame erste Builds?
repository_cache und Externals prüfen; oft fehlen Archive-Treffer, während Aktions-Cache bereits warm ist.
disk_cache auf NAS?
Nur mit Vorsicht: hohe Latenz und Lock-Probleme; lokale NVMe bevorzugen oder dedizierten Cache-Server per remote_cache.
Bzlmod-Registry zeitweise 5xx?
Spiegel-URL in MODULE.bazel oder Registry-Override nutzen; parallel http_timeout_scaling anheben.

Fazit

Fazit (2026): Stabile Bazel-CI auf Remote-Macs verbindet isolierte output_base-/Cache-Pfade, eine klare Strategie für repository_cache, disk_cache und remote_cache, hochskalierte HTTP-Timeouts und gedeckelte --jobs mit separater fetch-Phase. Wenn Ihre Pulls grenzüberschreitend hängen, lohnt sich die Wahl eines passend regionierten Knotens und eines nahen Artefakt-Caches oft mehr als weiteres Hochdrehen der Parallelität. Mieten oder kaufen Sie Apple-Silicon-Runner über die Startseite, vergleichen Sie Pakete auf Kaufen und Preise, und nutzen Sie Hilfe zu SSH & Verbindung ohne Pflicht-Login.

Bazel & Remote-Mac 2026

Nächste Schritte – ohne Login

Startseite, Pakete, Preise und Hilfe mit SSH-Anleitungen; Technik-Blog für CI- und Netz-Themen.

Zur Startseite Remote-Mac-Pakete Hilfe: SSH & Verbindung
Apple-Silicon-Remote-Macs
Bazel-Caches planbar
Technik-Blog