69 lines
3.0 KiB
Markdown
69 lines
3.0 KiB
Markdown
# 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ł.
|