infra/setup-buildx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: reflect runner-embedded cache and persistent buildkit

Browse Source 
The standalone gha-cache-server was removed; cache traffic now lands in
the act-runner's embedded Actions API (persisted on a 50Gi PVC). BuildKit
itself also moved to a 100Gi Longhorn PVC.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Anders Olsson
2026-05-23 22:48:26 +02:00
parent 7e63dcb42b
commit 917bedaf7c
1 changed files with 8 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+8 -5
View File
@@ -6,8 +6,8 @@ cluster.
Use this whenever a Gitea Actions workflow needs to build images. It removes Use this whenever a Gitea Actions workflow needs to build images. It removes
the boilerplate of declaring a remote driver every time, and ensures every the boilerplate of declaring a remote driver every time, and ensures every
build reuses the cluster's BuildKit + the GitHub Actions cache server build reuses the cluster's BuildKit instance (persistent 100 GiB Longhorn
(`gha-cache-server`) for layer caching. PVC + tuned GC) for layer caching across runs.
## Usage ## Usage
@@ -48,6 +48,9 @@ cluster does run a standalone BuildKit Service (`buildkit-service` Helm
chart, port 1234) which buildx can talk to via its `remote` driver. This chart, port 1234) which buildx can talk to via its `remote` driver. This
action wires that in by default. action wires that in by default.
The per-job runner pod already exports `ACTIONS_CACHE_URL` / `cache-from`/`cache-to: type=gha` also works out of the box: the act-runner
`ACTIONS_RUNTIME_TOKEN` pointing at `gha-cache-server`, so `cache-from`/ image (christopherhx/gitea-actions-runner) ships its own embedded Actions
`cache-to: type=gha` works without any extra config. Cache / Results API and injects `ACTIONS_CACHE_URL` / `ACTIONS_RUNTIME_TOKEN`
into the job container. That cache is persisted on the runner's `/data` PVC,
so it survives pod restarts. There is no separate cache-server deployment to
configure.