actions/resolve-buildx-cache/README.md

resolve-buildx-cache

Zamienia zmienne DOCKER_CACHE_* wystawiane przez runnera na opcje buildx.

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