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 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

1. Set up the Bitrise Build Cache for Bazel: Configuring the build cache for Bazel in the Bitrise CI environment.

2. Log in to Bitrise and select Bitrise CI on the left, then select your project.

3. Click the Workflows button on the main page.

4. In the Bitrise Build Cache for Bazel Step, set the Enable Bazel RBE input field to true.

Configuration YAML

1. Open your configuration YAML file.

2. Add the activate-build-cache-for-bazel Step 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

1. Start setting up the Bitrise Build Cache for Bazel: Configuring the build cache for Bazel in other CI environments.

2. When enabling the Bitrise Build Cache, add the --rbe flag.

   /tmp/bin/bitrise-build-cache activate bazel --cache --cache-push=false --rbe

   Cache

   We recommend setting the --cache-push flag to false because during remote build execution, workers upload results to the cache.

Local environment

1. Start setting up the Bitrise Build Cache for Bazel: Configuring the build cache for Bazel in local builds.

2. 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. We recommend adding them to your .bazelrc file so you can reuse them:

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>

Replace <pool-name> with the name of your worker pool. If you have worker pools in multiple data centers, use the same pool name in each data center so the same configuration works everywhere.

With everything in place, you can invoke Remote Build Execution by adding the remote config to any Bazel command:

bazel build //... --config=remote

What each flag does:

Flag and recommended values	Description
--jobs=100	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 underutilizes the RBE cluster. --jobs=100 is a good starting point for most Android/iOS monorepos but it can be increased gradually based on the worker count.
--remote_default_exec_properties=Pool=<pool-name>	Selects the worker pool that runs your remote actions. The value is the name of your worker pool as shown on Bitrise. The property set must match the worker pool exactly: make sure that no other exec_properties are set anywhere for the targets, otherwise Bazel will not match the worker pool and the build will fail.
--spawn_strategy=remote,local	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 remote,worker,sandboxed,local. Keep remote first so actions run in your remote execution environment, with a graceful fallback to local execution.
--noremote_upload_local_results	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 --cache-push flag is false or off in the CLI when you use this flag.

Selecting a worker pool per target

--remote_default_exec_properties applies to the whole invocation, and Bazel ignores it for any target whose execution platform sets its own exec_properties. To route different targets to different worker pools — for example, running tests on a pool with a different macOS image — define a platform for each pool and set the Pool property there:

platform(
    name = "macos_tests",
    constraint_values = [
        "@platforms//os:macos",
        "@platforms//cpu:arm64",
    ],
    exec_properties = {"Pool": "<pool-name>"},
)

Register the platform with --extra_execution_platforms and use standard Bazel platform and toolchain resolution to assign targets to it.