RBE Setup
Getting started with Remote Build Execution (RBE) is less daunting than it may seem. We've put together a guide that not only helps you get started with BuildBuddy RBE, but also helps you understand what is going on under the hood.
This guide assumes you're using BuildBuddy Cloud or BuildBuddy Enterprise on-prem.
#
The basicsThe very simplest Bazel command needed to enable RBE is the following:
This points Bazel at BuildBuddy Cloud as a remote executor. A simple repo that has C/C++/CGO or Java dependencies will build just fine like this. Most interesting repos have some dependencies on C/C++/CGO or Java - so we'll need to tell our remote executors where to find tools like gcc or the JRE. We do this with platforms and toolchains.
#
Configuring your workspaceThere are several options for configuring your platforms and toolchains, the most fully features of which being bazel-toolchains. It comes with an rbe_autoconfig
rule that works nicely with BuildBuddy.
Unfortunately, bazel-toolchains has a dependency on Docker and can take quite some time to start up in a clean workspace, so we provide a simple and easy-to-use BuildBuddy toolchain that enables you to get up and running quickly, and works for most use cases.
To get started with the BuildBuddy Toolchain, add the following lines to your WORKSPACE
file:
#
PlatformsThe first thing you'll want to do is tell BuildBuddy RBE in what environment you'll want to run your build actions. This is tools can be found in different locations on different platforms. This is done with the --host_platform
, --platforms
, and --extra_execution_platforms
flags.
BuildBuddy's default platform is Ubuntu 16.04 with Java 8 installed. We can specify this platform with the --host_platform
, --platforms
, and --extra_execution_platforms
flags:
If you want to use a different environment, you can specify a custom Docker container image to use. More information on how to do this can be found in our platforms documentation.
#
ToolchainsToolchains sound complicated (and they can be) - but the concept is simple. We're telling our remote executors where to find tools that are needed to build our code.
#
C toolchainThe first toolchain you'll likely run into the need for is a C/C++ compiler. Even if your code isn't written in one of these languages, it's likely that one of your dependencies is - or calls some C code with something like cgo.
You'll know you need a C toolchain when you see an error for a missing gcc or clang that looks like:
To use BuildBuddy's default C toolchain, we can use the --crosstool_top
and --extra_toolchains
flag:
If you're looking for an llvm based toolchain instead, take a look at this project.
#
Java toolchainIf your project depends on Java code, you'll need 4 more flags to tell the executors where to look for Java tools.
Using BuildBuddy's default Java 8 config:
If you need a different version of Java, we recommend using bazel-toolchains for now.
#
AttributesSome tools like Bazel's zipper (@bazel_tools//tools/zip:zipper) use an attribute to determine whether or not they're being run remotely or not. For tools like these to work properly, you'll need to define an attribute called EXECUTOR
and set it to the value remote
.
#
Putting it all togetherThis can be a lot of flags to tack onto each bazel build, so instead you can move these to your .bazelrc
file under the remote
config block:
And running:
#
AuthenticationYou'll want to authenticate your RBE builds with either API key or certificate based auth. For more info on how to set this up, see our authentication guide.
#
Configuration options#
--jobsThis determines the number of parallel actions Bazel will remotely execute at once. If this flag is not set, Bazel will use a heuristic based on the number of cores on your local machine. Your builds & tests can likely be parallelized much more aggressively when executing remotely. We recommend starting with 50
and working your way up.
#
--remote_timeoutThis determines the maximum time Bazel will spend on any single remote call, including cache writes. The default value is 60s. We recommend setting this high to avoid timeouts when uploading large cache artifacts.
#
--remote_download_minimalBy default, bazel will download intermediate results of remote executions - so in case an artifact isn't found in the remote cache, it can be re-uploaded. This can slow down builds in networks constrained environments.
This can be turned off with the flag:
While this flag can speed up your build, it makes them more sensitive to caching issues - and likely shouldn't be used in production yet.
#
--remote_instance_nameIf you'd like separate remote caches, whether it's for CI builds vs local builds or other reasons, you can use the remote_instance_name
flag to namespace your cache artifacts:
#
--disk_cacheWhile setting a local disk cache can speed up your builds, when used in conjunction with remote execution - your local and remote state has the opportunity to get out of sync. If you suspect you're running into this problem, you can disable your local disk cache by setting this to an empty value.
#
--incompatible_strict_action_envSome rules (like protobuf) are particularly sensitive to changes in environment variables and will frequently be rebuilt due to resulting cache misses. To mitigate this, you can use the incompatible_strict_action_env
which sets a static value for PATH
.
#
--action_envYou can set environment variables that are available to actions with the --action_env
flag. This is commonly used to set BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN
which tells bazel not to auto-detect the C++ toolchain.
#
--defineDefine allows you to assign build variables. This is commonly use to set EXECUTOR
to compile singlejar and ijar from source.
#
--spawn_strategySets the list of strategies in priority order from highest to lowest. Each action picks the highest priority strategy that it can execute. The default value is remote,worker,sandboxed,local
.
#
--strategyExplicitly setting strategies should no longer be needed for Bazel versions post 0.27.0. It can be used to force certain bazel mnemonics to be build remotely.
#
--experimental_inmemory_dotd_filesIf enabled, C++ .d files will be passed through in memory directly from the remote build nodes instead of being written to disk. This flag is automatically set when using --remote_download_minimal
.
#
--experimental_inmemory_jdeps_filesIf enabled, .jdeps files generated from Java compilations will be passed through in memory directly from the remote build nodes instead of being written to disk. This flag is automatically set when using --remote_download_minimal
.
#
Examples- buildbuddy-io/buildbuddy .bazelrc --config=remote
- graknlabs/grakn .bazelrc --config=rbe
- wix/exodus .bazlerc.remote
#
Advanced configurationIf you need a more advanced configuration than provided by the basic BuildBuddy toolchain, we recommend exploring Bazel's bazel-toolchains repo. Its rbe_autoconfig
rule is highly configurable and works nicely with BuildBuddy.
Here's a quick snippet you can add to your WORKSPACE
file if using bazel 3.6.0:
And to your .bazelrc
:
And then run: