Remote worker

This program implements a remote execution worker that uses gRPC to accept work requests. It can work as a remote execution worker, a cache worker, or both. The simplest setup is as follows:

• First build the worker and run it.

    bazel build src/tools/remote:all
    bazel-bin/src/tools/remote/worker \
        --work_path=/tmp/test \
        --listen_port=8080
  

• Then you run Bazel pointing to the worker instance.

    bazel build \
        --spawn_strategy=remote --remote_cache=localhost:8080 \
        --remote_executor=localhost:8080 src/tools/generate_workspace:all
  

The above command will build generate_workspace with remote spawn strategy that uses the local worker as the distributed caching and execution backend.

Sandboxing

If you run the worker on Linux, you can also enable sandboxing for increased hermeticity:

    bazel-bin/src/tools/remote/worker \
        --work_path=/tmp/test \
        --listen_port=8080 \
        --sandboxing \
        --sandboxing_writable_path=/run/shm \
        --sandboxing_tmpfs_dir=/tmp \
        --sandboxing_block_network

As you can see, the specific behavior of the sandbox can be tuned via the flags

• --sandboxing_writable_path= makes a path writable for running actions.
• --sandboxing_tmpfs_dir= will mount a fresh, empty tmpfs for each running action on a path.
• --sandboxing_block_network will put each running action into its own network namespace that has no network connectivity except for its own “localhost”. Note that due to a Linux kernel issue this might result in a loss of performance if you run many actions in parallel. For long running tests it probably won't matter much, though.