From 917bedaf7caf87425115f6fb7a9f37adb568a960 Mon Sep 17 00:00:00 2001 From: Anders Olsson Date: Sat, 23 May 2026 22:48:26 +0200 Subject: [PATCH] docs: reflect runner-embedded cache and persistent buildkit 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) --- README.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 0eb3647..860a2c5 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,8 @@ cluster. 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 -build reuses the cluster's BuildKit + the GitHub Actions cache server -(`gha-cache-server`) for layer caching. +build reuses the cluster's BuildKit instance (persistent 100 GiB Longhorn +PVC + tuned GC) for layer caching across runs. ## 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 action wires that in by default. -The per-job runner pod already exports `ACTIONS_CACHE_URL` / -`ACTIONS_RUNTIME_TOKEN` pointing at `gha-cache-server`, so `cache-from`/ -`cache-to: type=gha` works without any extra config. +`cache-from`/`cache-to: type=gha` also works out of the box: the act-runner +image (christopherhx/gitea-actions-runner) ships its own embedded Actions +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.