2026: Bazel на удалённом Mac — внешние pull, WORKSPACE и матрица remote cache для CI

На Apple Silicon в CI дорогой этап редко бывает первым вызовом компилятора — чаще это разрешение репозиториев. Правила в духе http_archive, git_repository и кастомные макросы в WORKSPACE качают архивы и Git-объекты по HTTPS. Путь Bzlmod идёт через модульный реестр, но в конце всё равно упирается в tarball’ы и Git-хосты. Трансграничные линки добавляют разброс RTT, инспекцию TLS на периметре и кратковременные обрывы, которые в логе выглядят как repository failed, а не как ошибка компиляции.

Диск участвует дважды: repository cache хранит неизменяемые загрузки по содержимому, а распакованные деревья оказываются под $(bazel info output_base)/external. Если output_base делит том с горячим --disk_cache, параллельные анализы от разных job перемешивают случайные записи выходов действий с последовательными распаковками внешних правил. Рассматривайте сеть и IO как одну систему: при низкой задержке до registry, но джиттере сборки сначала смотрите пропускную способность тома, а не спешите поднимать --jobs.

Перед закупкой диска или включением общего endpoint сверьтесь с таблицей. --disk_cache кеширует выходы действий локально; --remote_cache (gRPC или HTTP) разделяет их между машинами. Третья опора — --repository_cache: дедуплицирует апстрим-загрузки и чаще всего даёт максимальный эффект при трансграничном CI.

Рычаг параллелизма действий — --jobs=N. На сборках, тяжёлых по fetch, высокое N до прогрева repository cache увеличивает число одновременных распаковок и конкурирует с писателями disk cache: начинайте консервативно, смотрите IO wait, затем наращивайте.

Закрепите значения в проверяемом .bazelrc или генерируемом CI-фрагменте. Пути и секреты подставляйте из оркестратора; живые токены в публичный репозиторий не коммитьте — передавайте --remote_header из переменных окружения job.

Иллюстративный фрагмент (в проде разбейте по профилям):

# Общий пролог CI (пути — пример)
common --repository_cache=/usr/local/ci/bazel-repo-cache
common --experimental_repository_downloader_retries=5
build --disk_cache=/usr/local/ci/bazel-disk-cache
build --remote_cache=grpcs://bazel-cache.internal.example:443
build --remote_timeout=600
# build --remote_header=Authorization=Bearer ${BAZEL_CACHE_TOKEN}

Проверка: один прогревочный job — bazel fetch //… или цель в режиме анализа, затем включайте матрицу. На первой неделе раската добавьте --verbose_failures в лог CI.

Размещайте раннер ближе к реестрам и зеркалам, которые реально использует пайплайн. Удалённый Mac в регионе A с remote cache в регионе B может сократить время компиляции, но съесть выигрыш на аплоаде/скачивании крупных промежуточных артефактов. При нестабильном трансграничном канале соразмещайте endpoint кеша, хранилище артефактов и сам раннер.

Высокий --jobs усиливает нагрузку на CPU и диск, пока правила репозиториев могут продолжать потоковые загрузки. Сдвигайте ноги матрицы по времени, ограничивайте число одновременных инвокаций Bazel на хосте или выделите один «fetch»-job, который заполняет --repository_cache до fan-out. Эта логика совпадает с рекомендациями в FAQ по параллельным pull и диску: Bazel — ещё один тяжёлый потребитель того же IO-бюджета.

Bazel на удалённом Mac в CI чаще всего ломается на слое загрузок: для трансграничной стабильности в первую очередь настройте --repository_cache, затем выбирайте --disk_cache или --remote_cache по числу хостов и политике повторного использования, и ограничивайте --jobs реальной пропускной способностью диска. Shallow clone сочетайте осознанно с неизменяемыми SHA, а endpoint кеша держите в одном регионе с раннерами, если узкое место — WAN.

Готовы вынести fetch-тяжёлые сборки на выделенный Apple Silicon: откройте главную, сравните тарифы и узлы, оформите покупку или аренду без лишних шагов. Вопросы по SSH и подключению — в центре помощи; больше сценариев CI — в техническом блоге.