mirror of
https://gerrit.hackerspace.pl/hscloud
synced 2025-03-19 05:04:52 +00:00
Serge Bazanski
5de0b32e3b
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 |
||
|---|---|---|
| .. | ||
| BUILD.bazel | ||
| main.go | ||
| README.md | ||
| service.go | ||
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.