feat: add resolve-buildx-cache as a shared composite action

2026-08-09 15:09:25 +02:00
commit 4dee87df56
3 changed files with 180 additions and 0 deletions
@@ -0,0 +1,68 @@
+# resolve-buildx-cache
+
+Zamienia zmienne `DOCKER_CACHE_*` wystawiane przez runnera na opcje buildx.
+
+```yaml
+      - name: Resolve buildx cache settings
+        id: cache
+        uses: https://git.cierzniak.it/gitea-runner/actions/resolve-buildx-cache@v1
+        with:
+          cache-image: ${{ github.repository }}/app
+
+      - uses: docker/setup-buildx-action@v4
+        with:
+          driver-opts: ${{ steps.cache.outputs.driver-opts }}
+
+      - uses: docker/build-push-action@v7
+        with:
+          cache-from: ${{ steps.cache.outputs.cache-from }}
+          cache-to: ${{ steps.cache.outputs.cache-to }}
+```
+
+## Wejście i wyjście
+
+| Input | Wymagany | Co to |
+| --- | --- | --- |
+| `cache-image` | tak | Ścieżka obrazu cache'a bez hosta rejestru, np. `org/repo/app`. Ref powstaje jako `<DOCKER_CACHE_SERVER>/<cache-image>:cache` |
+
+| Output | Do czego |
+| --- | --- |
+| `driver-opts` | `driver-opts` dla `docker/setup-buildx-action` |
+| `cache-from` | `cache-from` dla `docker/build-push-action` |
+| `cache-to` | `cache-to` dla `docker/build-push-action` |
+
+Każdy job budujący osobny obraz podaje własny `cache-image` — inaczej cztery buildy
+nadpisywałyby sobie jeden wpis w rejestrze.
+
+## Zmienne runnera
+
+Czytane jako zwykłe env joba z `runner.envs` w `config.yaml` runnera, **nie** przez kontekst
+`vars.*` — ten widzi wyłącznie zmienne zdefiniowane po stronie Gitei. Runnery czytają
+`config.yaml` przy starcie, więc po zmianie trzeba je zrestartować.
+
+| Zmienna | Znaczenie |
+| --- | --- |
+| `DOCKER_CACHE_TYPE` | typ cache'a buildx, w praktyce `registry` |
+| `DOCKER_CACHE_SERVER` | host rejestru cache'a, np. `registry:5000` |
+| `DOCKER_CACHE_NETWORK` | sieć Compose, do której trzeba podpiąć buildkita, żeby zobaczył rejestr |
+
+## Dlaczego tak
+
+**Puste `DOCKER_CACHE_TYPE`/`DOCKER_CACHE_SERVER` degradują joba do buildu bez cache'a**
+(`::warning::` w logu), zamiast go wywalać. Cache jest optymalizacją; brak konfiguracji na
+nowej puli runnerów nie ma prawa zatrzymać wdrożenia.
+
+**`DOCKER_CACHE_NETWORK` nie jest wpisany na sztywno.** Buildkit startuje jako osobny
+kontener poza siecią stacku runnerów, więc przy rejestrze stojącym w tej sieci trzeba go
+podpiąć jawnie. Ale przy flotach w LXC, gdzie rejestr ma własne IP, nie ma do czego się
+podpinać, a `network=<nieistniejąca>` wywala joba twardo. Dlatego pusta wartość oznacza
+„nie przekazuj `driver-opts` wcale" — repo nie zna topologii runnera i nie ma czego zgadywać.
+
+**`registry.insecure=true` w refach**, bo rejestr cache'a chodzi po HTTP bez TLS-a.
+Zastępuje to wcześniejszy `buildkitd-config-inline` z blokiem `[registry."..."]`, który przy
+pustej zmiennej generował `[registry.""]` — blok składniowo zepsuty, a nie błąd.
+
+**Wartości jadą z runnera, nie z `vars.*` Gitei**, bo każda pula ma własny rejestr cache'a
+i wskazuje na siebie. Gdy siedziały jako zmienne organizacji, po przeniesieniu na runnery
+`vars.DOCKER_CACHE_*` rozwiązywało się do pustego stringa — build leciał na zielono bez
+cache'a i nikt tego nie zauważył.