Bazelのリモートビルド実行
Bazelビルドのリモート実行により、ビルドおよびテストのアクションを複数のマシンに分散できます。これにより、ビルドとテストの実行が高速化され、開発チーム間でビルド出力を再利用でき、一貫した環境が得られます。
Bitrise Build CacheのRemote Build Executionは、Bitrise上でも、Bitrise CI以外の環境でも使用できます。
BitriseでのRemote Build Executionの設定Click to copy link
- Workflow Editor
- Configuration YAML
-
Set up Bitrise Build Cache for Bazel: Bitrise CI環境でのBazel用build cacheの設定を参照してください。
-
Bitrise にアクセスして Log in、左側の Bitrise CI を選択し、プロジェクトを選択します。
-
メインページの Workflows ボタンをクリックします。
-
Bitrise Build Cache for BazelのStepで、Enable Bazel RBE入力フィールドをtrueに設定します。
-
の設定YAMLファイルを開きます。
-
activate-build-cache-for-bazelStepをWorkflowに追加します。your-workflow:steps:- git-clone: {}- activate-build-cache-for-bazel:inputs:- enable_rbe: true
Bitrise以外の環境でのRemote Build Executionの設定Click to copy link
- Non-Bitrise CI
- Local environment
-
Bitrise Build Cache for Bazelの設定を開始します: Bitrise CI以外の環境でのBuild Cache for Bazelの設定を参照してください。
-
Bitrise Build Cacheを有効にするときに、
--rbeフラグを追加します。bitrise-build-cache activate bazel --cache --cache-push=false --rbeキャッシュリモートビルド実行中はワーカーが結果をキャッシュにアップロードするため、
--cache-pushフラグはfalseに設定することをおすすめします。
-
Bitrise Build Cache for Bazelの設定を開始します: ローカルビルドでのBazel用build cache の設定を参照してください。
-
RBEエンドポイントの設定を
.bazelrcに追加します。build:remote --remote_executor=grpcs://bitrise-accelerate.services.bitrise.io:443
Remote Build Executionの推奨フラグClick to copy link
Bazelには、Remote Build Executionを最大限に活用するために必要なコマンドフラグが数多くあります。再利用できるように、これらを.bazelrcファイルに追加することをおすすめします。
build:remote --jobs=100
build:remote --noremote_upload_local_results
build:remote --spawn_strategy=remote,local
build:remote --remote_default_exec_properties=Pool=<pool-name>
<pool-name>をworker poolの名前に置き換えてください。複数のデータセンターにworker poolがある場合は、どのデータセンターでも同じ設定が使えるように、各データセンターで同じpool nameを使用してください。
準備が整ったら、任意のBazelコマンドにremote configを追加することで、Remote Build Executionを呼び出せます。
bazel build //... --config=remote
各フラグの役割は次のとおりです。
| フラグと推奨値 | 説明 |
|---|---|
--jobs=100 | Bazelが同時に「実行中」にできるビルド/テストアクションの最大数を定義します。このフラグを省略すると、Bazelは暗黙的にホストVMの論理CPUコア数にフォールバックします。このデフォルト値はローカル実行には適していますが、RBEクラスターを大幅に使い切れません。--jobs=100は、ほとんどのAndroid/iOSモノレポで適切な開始値であり、ワーカー数に応じて段階的に増やせます。 |
--remote_default_exec_properties=Pool=<pool-name> | リモートアクションを実行するworker poolを選択します。値は、Bitriseに表示されるworker poolの名前です 。プロパティセットはworker poolと完全に一致する必要があります。ターゲットに対して他のexec_propertiesがどこにも設定されていないことを確認してください。設定されていると、Bazelはworker poolと一致せず、ビルドが失敗します。 |
--spawn_strategy=remote,local | Bazelがアクションの実行を試みる順序を決定します。Bazelは、リスト内で指定のアクションを実行できる最初のストラテジーを使用します。default valueはremote,worker,sandboxed,localです。リモートを先頭に置くことで、アクションがリモート実行環境で実行され、ローカル実行へ円滑にフォールバックします。 |
--noremote_upload_local_results | ローカルで生成された出力の再アップロードをスキップします。リモートワーカーはすでにアーティファクトをキャッシュにプッシュしているため、帯域幅を節約できます。このconfigフラグは、Bitrise Build Cache CLIでも設定されます。これを使用する場合は、このフラグの使用時にCLIで--cache-pushフラグがfalseまたはoffになっていることを確認してください。 |
ターゲットごとのworker poolの選択Click to copy link
--remote_default_exec_propertiesは呼び出し全体に適用され、実行プラットフォームが独自のexec_propertiesを設定しているターゲットについては、Bazelはこれを無視します。たとえば、異なるmacOSイメージを持つプー ルでテストを実行するなど、ターゲットごとに異なるworker poolにルーティングするには、プールごとにプラットフォームを定義し、そこでPoolプロパティを設定します。
platform(
name = "macos_tests",
constraint_values = [
"@platforms//os:macos",
"@platforms//cpu:arm64",
],
exec_properties = {"Pool": "<pool-name>"},
)
--extra_execution_platformsでプラットフォームを登録し、標準のBazelプラットフォームとツールチェーンの解決を使用して、ターゲットをそのプラットフォームに割り当てます。