リモート Mac の Bazel CI では 外源 と キャッシュ階層の誤用 がボトルネックになりやすいです。
--disk_cache／--repository_cache／--remote_cache、--jobs、Git 浅複製の IO を閾値表と .bazelrcに整理します。
リモート Mac における Bazel 外源・レジストリのボトルネック像
軸は RTT×ホップ と 同時フェッチ。外源ルールは TLS・帯域を直撃し、共有ランナーでは repository_cache 競合 でタイムアウト表示のディスク待ちも起きます。
| 症状 | 疑い | 切り分け |
|---|---|---|
| fetch 長停／毎回重い | 外源 or repository_cache | 単独 fetch＋キャッシュパス固定 |
| 並列でランダム失敗 | FD／帯域 | --jobs×concurrency を下げる |
ミラー運用は 跨境 Git／ミラー最適化 と併読。
disk cache と remote cache の選定しきい値表
--repository_cache＝外源取得、--disk_cache＝ローカル成果物、--remote_cache＝チーム共有の順で覚えると取り違えません。
| 条件 | 推奨 | 要点 |
|---|---|---|
| 単一ランナー・大容量ディスク | repository_cache＋disk_cache | fetch／再ビルドが安い |
| 複数 Mac で成果物共有 | remote_cache 追加 | アーティファクト再利用 |
| ディスク逼迫・高並列 | remote_cache 主、ローカル縮小 | inode／容量枯渇を避ける |
.bazelrc 断片
common --repository_cache=~/.cache/bazel-repo
build --disk_cache=~/.cache/bazel-disk
build --remote_cache=grpcs://bazel-cache.example.com:443
build --remote_upload_local_results=true
JVM 並走時は Gradle／Maven マトリクス と ボリューム単位でキャッシュパスを分離。
WORKSPACE／MODULE フェッチ失敗：再試行・timeout パラメータ
フラグ名は Bazel メジャー依存 のため .bazelversion＋bazelisk 固定後、bazel help build で HTTP／repository 系を確認します。
| 項目 | 置き場所 | メモ |
|---|---|---|
| 版固定 | .bazelversion | フラグ互換の前提 |
| registry | common --registry=… | README と同一 URL |
| 再試行・timeout | common | 版対応のみ列挙 |
| fetch 分離 | CI | fetch 後に test／build |
チェック：--verbose_failures で URL を残す／CI 再試行は 2s・4s・8s 最大 3 回／ロックは別 PR。
Git 浅複製と並行するディレクトリ・IO FAQ
メイン --depth 1 と Bazel 外源は IO が別。浅複製＋archive＋高 --jobs はディスク飽和をネットエラーに見せます。repository_cache は永続ボリューム、inode も監視。複数パイプラインは 並列 pull・ディスク FAQ の上限表を参照。
ノード地域と並列コンパイルが fetch 安定性に与える影響
鏡が遠いと fetch が伸び、--jobs がディスク帯域を奪います。ノードをソース近傍に、跨境チームは fetch を直列化、--jobs はコアの 0.5〜0.75 倍から試し、ヒット率を見て上げます。