Bazel client
Bazel is a “fast, scalable, multi-language and extensible build system” that supports remote build execution using the remote execution API (REAPI) v2 since its 0.17 release.
Configuration
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,
including:
--remote_executor: remote execution endpoint’s location,{host}:{port}.--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 .bazelrc with:
build --spawn_strategy=remote --remote_executor=grpc://controller.grid.build:50051 --remote_instance_name=main
Example build
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:
cd bazel-examples/cpp-tutorial/stage3
Hint
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.yml file in the root directory:
server:
- !channel
address: localhost:50051
insecure-mode: true
connections:
- !sql-connection &sql
connection-string: postgresql://bgd:insecure@database/bgd
pool-size: 5
pool-timeout: 30
max-overflow: 10
storages:
- !lru-storage &main-storage
size: 512MB
caches:
- !lru-action-cache &main-action
storage: *main-storage
max-cached-refs: 256
allow-updates: true
schedulers:
- !sql-scheduler &scheduler
sql: *sql
storage: *main-storage
action-cache: *main-action
poll-interval: 0.5
max-execution-timeout: 7200
instances:
- name: ''
services:
- !action-cache
cache: *main-action
- !execution
scheduler: *scheduler
- !cas
storage: *main-storage
- !bytestream
storage: *main-storage
thread-pool-size: 100
This defines a single main server instance implementing a
ContentAddressableStorage (CAS) + ByteStream service together with an
Execution + ActionCache service, both using the same in-memory storage.
You can then start the BuildGrid server daemon using that configuration by
running:
bgd server start server.yml
In order to perform the actual build work, you need to attach a worker bot to
that server for that main instance. Once you’ve make sure that your machine
has gcc installed, run:
buildbox-casd --cas-remote=http://localhost:50051 --bind=127.0.0.1:50011 ~/casd &
buildbox-worker --buildbox-run=buildbox-run-hosttools --bots-remote=http://localhost:50051 \
--cas-remote=http://127.0.0.1:50011 --request-timeout=30 my_bot
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 .bazelrc
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 main remote
execution server instance at localhost:50051.
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:
./bazel-bin/main/hello-world