# 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ł.