Bazel Remote Execution

Run Bazel actions on Namespace compute, with remote workers started on demand for your build.

Remote Execution is in early access. Reach out to enable it for your workspace.

How it works

A Bazel Remote Execution cluster has three components:

  • Scheduler: accepts Bazel Remote Execution API requests and assigns actions to workers.
  • Storage: stores content-addressable storage (CAS) entries durably across the cluster.
  • Workers: start on demand and execute Bazel actions.

Each worker advertises a fixed number of execution slots. A slot represents one unit of concurrent work, so a worker with four slots can run up to four actions at the same time. Namespace starts workers as your build needs capacity and routes actions to workers that match the requested execution platform.

Bazel's remote execution protocol supports multi-platform builds. For example, you can run Bazel from a Linux host while selected actions execute on macOS workers. This is useful for repositories that need to produce or test artifacts on multiple operating systems without moving the entire CI job to each platform.

Getting started

First, make sure your workspace has early-access RBE enabled. Then use the CLI to create a Bazel configuration file for the execution cluster:

Configure execution access

$
nsc bazel execution setup --bazelrc=~/.namespace.bazelrc

This command provisions the scheduler and storage components if needed and writes a Bazel configuration file with the remote executor, remote cache, credentials, and recommended execution defaults.

Run Bazel with remote execution

$
bazel --bazelrc=~/.namespace.bazelrc build //...

You can pass multiple --bazelrc flags if you need to combine Namespace's generated configuration with your existing project configuration.

For a quick early-access smoke test, generate a configuration file:

$ nsc bazel execution setup --bazelrc=~/.namespace.bazelrc --key=docs-smoke-test

If the command succeeds, Namespace provisioned the execution cluster and wrote a Bazel configuration file that points at it.

Example: Linux host to Linux workers

This example runs Bazel from a Linux host and lets Namespace execute actions on Linux workers. It uses a public Bazel repository so you can try the flow without changing your own project first.

$ git clone https://github.com/bazelbuild/examples.git
$ cd examples/cpp-tutorial/stage3
 
$ nsc bazel execution setup --bazelrc=~/.namespace.bazelrc --key=examples-linux
$ bazel --bazelrc=~/.namespace.bazelrc build //...

By default, actions without explicit platform properties are routed to Linux workers.

Example: Linux host to macOS workers

Bazel can also route selected actions to macOS workers from a Linux client. The linux-to-mac-rbe-demo repository demonstrates that setup.

This example requires macos/arm64 workers to be enabled for your workspace. If you see an error such as no on-demand worker capacity configured for platform "macos/arm64", reach out to the Namespace team to enable macOS worker capacity.

$ git clone https://github.com/namespacelabs/linux-to-mac-rbe-demo.git
$ cd linux-to-mac-rbe-demo
 
$ nsc bazel execution setup --bazelrc=~/.namespace.bazelrc --key=linux-to-mac-demo
$ bazelisk --bazelrc=~/.namespace.bazelrc build //DemoApp:DemoApp

For your own targets, route an action to macOS by setting Bazel execution properties on that target or platform, for example:

exec_properties = {
    "OSFamily": "macos",
    "Arch": "arm64",
}

Actions without macOS execution properties continue to run on the default Linux workers, allowing one Bazel invocation to use both platforms.

Current caveats

Remote Execution is still early and the experience is actively changing:

  • Worker sizing is not yet self-service. Reach out to the Namespace team to change worker shapes or slot counts.
  • Revocable tokens are not yet usable with Bazel Remote Execution.
  • Worker base images cannot be modified self-service yet.
  • Action observability is still missing.
  • Actions are not sandboxed from each other when running in the same worker, but workers are never shared across workspaces.
  • Action input hydration and result upload performance still needs further work.

If any of these caveats block your use case, contact support@namespace.so so we can help choose the right rollout path.

Last updated