Bazel accepts many options that can either be specified as command line
arguments when invoking the
bazel tool or stored in a .bazelrc
configuration file. In order to activate remote build execution, the
bazel build subcommand needs to be given specific build options,
--remote_executor: remote execution endpoint’s location,
--remote_instance_name: remote execution instance’s name.
--spawn_strategy: action execution method.
Spawn strategies need to be set to
remote for remote execution.
As an example, in order to activate remote execution on the
main instance of
the remote execution server available at
controller.grid.build on port
50051 you should amend your
build --spawn_strategy=remote --remote_executor=grpc://controller.grid.build:50051 --remote_instance_name=main
The bazel-examples repository contains example Bazel workspaces that can be used for testing purpose. We’ll focus here on instructions on how to build the stage3 CPP example running Bazel and BuildGrid on your local machine, compiling the C++ source code using host-tools.
First, you need to checkout the bazel-examples repository sources:
git clone https://github.com/bazelbuild/examples.git bazel-examples
Next, change the current directory to the Bazel workspace root:
All the commands in the instructions below are expected to be executed from that root directory (the stage3 example workspace’s root directory).
Before running Bazel and building the example workspace, you’ll have to setup
and run a BuildGrid server and bot. A minimal server’s configuration is given
below, paste it in a
server.conf file in the root directory:
server: - !channel port: 50051 insecure-mode: true instances: - name: main storages: - !lru-storage &main-storage size: 512MB services: - !action-cache &main-action storage: *main-storage max-cached-refs: 256 allow-updates: true - !execution storage: *main-storage action-cache: *main-action - !cas storage: *main-storage - !bytestream storage: *main-storage
This defines a single
main server instance implementing a
ContentAddressableStorage (CAS) +
ByteStream service together with an
ActionCache service, both using the same in-memory storage.
You can then start the BuildGrid server daemon using that configuration by
bgd server start server.conf
In order to perform the actual build work, you need to attach a worker bot to
that server for that
main instance. A simple host-tools based bot should be
enough to build the stage3 CPP example. Once you’ve make sure that your machine
gcc installed, run:
bgd bot --remote=http://localhost:50051 --instance-name=main host-tools
--remote option is used to specify the server location (running on the
same machine here, and listening to port 50051). The
--instance-name option is used
to specify the server instance you expect the bot to be attached to. Refer to
the CLI reference section for command
line interface details.
The BuildGrid server is now ready to accept jobs and execute them. Bazel needs
some configuration in order to run remote builds.
Below are the minimal build options you should use, paste them in a
file in the root directory:
build --spawn_strategy=remote --remote_executor=grpc://localhost:50051 --remote_instance_name=main
This activates Bazel’s remote execution mode and points to the
execution server instance at
You can finally have Bazel to build the example workspace by running:
bazel build //main:hello-world
You can verify that the example has been successfully built by running the generated executable. Simply invoke: