tree: a797773d0d0bd77910503df5dfb0d5b1ec3455b4 [path history] [tgz]
  1. BUILD.bazel
  2. main.go
  3. README.md
  4. service.go
devtools/ci/remote-cache/README.md

remote-cache

A small Go service that acts as a Bazel remote cache HTTP server and is backed in Ceph.

Status

Work in progress, does not run on prod yet, needs write authentication support first.

Building

bazel build //devtools/ci/remote-cache

Running locally

For now, you'll have to manually acquire some Ceph RadosGW/S3 keys. When you have them:

bazel run //devtools/ci/remote-cache -- \
    -object_access_key YOURACCESSKEY -object_secret_key yourSecretAccessKey -object_bucket your-bucket

Then, tell Bazel to connect when building something:

bazel build --remote_cache=http://127.0.0.1:8080 //cluster/prodvider

You should see something like this, if you ended up mostly doing GETs:

INFO: Elapsed time: 40.149s, Critical Path: 30.40s
INFO: 705 processes: 705 remote cache hit.
INFO: Build completed successfully, 718 total actions

This will be slower than building without cache if you mostly PUT cache elements, and will likely even be slower on GETs unless you have excellent connectivity to k0. The remote cache is only a building block used to make builds faster, and we will need more things (eg. Remote Build Execution and CI) to actually get speedups for developer builds.