Skip to content
Documentation

Docs / Adapter commands / Bazel REAPI

Bazel REAPI adapter

Reuse Bazel REAPI build results through a shared REAPI cache while the tool keeps control of task identities and local execution.

Command
boringcache bazel-reapi
Protocol
REAPI gRPC action cache and content-addressable store; cache only
Action
mode: bazel-reapi

How the adapter works

Native client configuration

Choose `bazel` for HTTP or `bazel-reapi` for gRPC. Both download top-level outputs by default. Set download-outputs to all, toplevel, or minimal; remote-max-connections sets the connection limit. HTTP and REAPI cache entries use different namespaces; selecting the same tag does not migrate entries between protocols.

Shared cache lifecycle

The adapter selects the cache tag, starts a loopback REAPI endpoint, runs the client, and drains cache writes before shutdown. A cache miss runs the task locally.

Read and write policy

Read-only runs do not publish cache entries. Trusted writable runs may publish. Unknown or misplaced adapter options fail before cache startup.

Set up Bazel REAPI

Commit this configuration and run boringcache bazel-reapi. Omit command when the Action should prepare caching for several later commands. Choose bazel for HTTP or bazel-reapi for gRPC. Both download top-level outputs by default. Set download-outputs to all, toplevel, or minimal; remote-max-connections sets the connection limit. HTTP and REAPI cache entries use different namespaces; selecting the same tag does not migrate entries between protocols.

workspace = "my-org/my-project"

[adapters.bazel-reapi]
tag = "bazel-reapi-build"
command = ["bazel", "build", "//..."]

[adapters.bazel-reapi.options]
download-outputs = "toplevel"
remote-max-connections = 64

Before the first run

  • Install the project’s Bazel REAPI version before running the adapter.
  • Review boringcache bazel-reapi --dry-run --json before the first build.
  • Remote execution is not provided; use an empty REAPI instance name.

Building inside Docker? Follow the Docker REAPI tool-cache setup to select this tool, its cache tag, and its read/write policy.

Use the same adapter in GitHub Actions

A committed adapter command runs in this Action step. Without one, the Action prepares caching for later tool commands and removes its temporary configuration after stopping the client and cache service.

.github/workflows/ci.yml 
- uses: boringcache/one@696d081c557c070471a175d72aa67d27709a3f31 # v1.40.0
  with:
    trust-policy: auto
    mode: bazel-reapi

Approve the repository through Connect CI and grant the job contents: read and id-token: write. The Action uses that Machine connection. Pull requests restore by default; trusted jobs may publish. See the authentication example in the GitHub Actions reference for scoped credentials when OIDC is unavailable.

GitHub Actions reference

Benchmarks

Native client cold and warm cache qualification is separate from an OSS project benchmark. No project speedup is claimed for this managed adapter.

All benchmarks

Tool reference

Check the tool's own reference when you need cache-key rules, build settings, or version-specific behavior.

All adapter commands

Compare every supported command, protocol, and Action mode in one place.

Adapter command index →

Need help or found something unclear? Open an issue or browse the CLI repo.