By default, all BuildBuddy executors are placed in a single pool - and any task can run on any executor (running the same operating system and cpu architecture).
Platforms can be used to specify custom Docker images in which to run your actions, but sometimes you want control over more properties of the executor machine - like available memory, access to GPUs, or physical location.
To support these use cases, BuildBuddy allows executors to be registered in different pools - and for Bazel to select from these pools at either the Platform level or the target level, depending on your needs.
When creating an executor deployment, you can specify the name of the pool its executors should be registered to with the
MY_POOL environment variable. This can be set to any string value.
By default, both executors and the BuildBuddy app do not set a pool name and any RBE request that comes in without a
Pool property set will be sent to the default pool. If you'd like requests without a
Pool property to be sent to a different default pool, you can set the app's
default_pool_name in the
remote_execution block of its
Now that you've deployed multiple executor pools, you can select which pool you'd like your builds to run on - either at the platform level or the target level.
You can configure BuildBuddy RBE to use a custom executor pool at the platform level, by adding the following rule to a BUILD file:
Make sure to replace
my-gpu-pool with your docker image url.
You can then pass this configuration to BuildBuddy RBE with the following flag:
This assumes you've placed this rule in your root BUILD file. If you place it elsewhere, make sure to update the path accordingly.
If you want different targets to run in different RBE environments, you can specify
exec_properties at the target level. For example if you want to run one set of tests in a high-memory pool, or another set of targets on executors with GPUs.