Remote build execution for Bazel
Remote execution of a Bazel build allows you to distribute build and test actions across multiple machines. This speeds up build and test execution, allows reuse of build outputs across development teams, and provides
Remote execution of a Bazel build allows you to distribute build and test actions across multiple machines. This speeds up build and test execution, allows reuse of build outputs across development teams, and provides a consistent environment.
You can use the Bitrise Build Cache with remote build execution both on Bitrise and in a non-Bitrise CI environment.
Configuring remote build execution on Bitrise
Workflow Editor
Configuration YAML
-
Set up the Bitrise Build Cache for Bazel: Configuring the Bitrise Build Cache for Bazel in the Bitrise CI environment.
-
Log in to Bitrise and select Bitrise CI on the left, then select your project.
-
Click the Workflows button on the main page.
-
In the Bitrise Build Cache for Bazel Step, set the Enable Bazel RBE input field to .
-
Open your configuration YAML file.
-
Add the
activate-build-cache-for-bazelStep to your Workflow.your-workflow: steps: - git-clone: {} - activate-build-cache-for-bazel: inputs: - enable_rbe: true
Configuring remote build execution in a non-Bitrise environment
Other CI
Local environment
-
Start setting up the Bitrise Build Cache for Bazel: Configuring the Build Cache for Bazel in non-Bitrise CI environments.
-
When enabling the Bitrise Build Cache, add the
--rbeflag./tmp/bin/bitrise-build-cache activate bazel --cache --cache-push=false --rbe
Cache
We recommend setting the
--cache-pushflag to false because during remote build execution, workers upload results to the cache.
-
Start setting up the Bitrise Build Cache for Bazel: Configuring the Bitrise Build Cache for Bazel in local environments.
-
Add the RBE endpoint config to your
.bazelrc:build:remote --remote_executor=grpcs://bitrise-accelerate.services.bitrise.io:443
Recommended flags for remote build execution
Bazel offers a number of command flags that are needed to get the most out of remote build execution.
|
Flag and recommend values |
Description |
|---|---|
|
|
Defines the maximum number of build/test actions Bazel may have "in flight" at once. If you omit the flag Bazel silently falls back to the number of logical CPU cores on the host VM. That default is appropriate for local execution but severely under‑utilises the RBE cluster.
|
|
MacOS:
Linux:
|
Defines the default execution platform (worker pool). Supply key‑value pairs such as Make sure that no other |
|
|
Determines the order in which Bazel tries to execute an action. Bazel will use the first strategy in the list that can run a given action. The default value is Keep remote first so actions run in your remote execution environment, with a graceful fallback to local execution. |
|
|
Skips re‑uploading outputs that were produced locally. Remote workers already push artifacts to the cache, saving bandwidth. This config flag is also configured via Bitrise Build Cache CLI. If you use it, please make sure that |
We recommend adding these flags to your .bazelrc file and reuse:
MacOS:
build:remote --jobs=100 build:remote --noremote_upload_local_results build:remote --spawn_strategy=remote,local build:remote --remote_default_exec_properties=Arch=arm64 build:remote --remote_default_exec_properties=OSFamily=Darwin
Linux:
build:remote --jobs=100 build:remote --noremote_upload_local_results build:remote --spawn_strategy=remote,local build:remote --remote_default_exec_properties=Arch=amd64 build:remote --remote_default_exec_properties=OSFamily=Linux
With everything in place, you can invoke remote build execution by adding the remote config to any Bazel command:
bazel build //... --config=remote