1
0
Fork 0
hscloud/devtools/ci/remote-cache
q3k 5de0b32e3b devtools/ci/remote-cache: init
This is a first pass at a Bazel remote cache. It notably does not yet do
any authentication, upload limits or garbage collection.

We won't be deploying it to prod until these are done.

Change-Id: I70a89dbe8b3ec933b2ce82e234a969e8337ba1d9
2021-03-20 13:15:18 +00:00
..
BUILD.bazel devtools/ci/remote-cache: init 2021-03-20 13:15:18 +00:00
README.md devtools/ci/remote-cache: init 2021-03-20 13:15:18 +00:00
main.go devtools/ci/remote-cache: init 2021-03-20 13:15:18 +00:00
service.go devtools/ci/remote-cache: init 2021-03-20 13:15:18 +00:00

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.