mirror of
https://gerrit.hackerspace.pl/hscloud
synced 2025-03-15 07:54:52 +00:00
Serge Bazanski
97b5cd7b58
This is a mega-change, but attempting to split this up further is probably not worth the effort. Summary: 1. Bump up bazel, rules_go, and others. 2. Switch to new go target naming (bye bye go_default_library) 3. Move go deps to go.mod/go.sum, use make gazelle generate from that 4. Bump up Python deps a bit And also whatever was required to actually get things to work - loads of small useless changes. Tested to work on NixOS and Ubuntu 20.04: $ bazel build //... $ bazel test //... Change-Id: I8364bdaa1406b9ae4d0385a6b607f3e7989f98a9 Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1583 Reviewed-by: q3k <q3k@hackerspace.pl> |
||
|---|---|---|
| .. | ||
| 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.