# build-site-with-hugo

Instaluje Hugo w podanej wersji i buduje stronę do `public/`.

```yaml
      - uses: actions/checkout@v7
      - uses: https://git.cierzniak.it/gitea-runner/actions/build-site-with-hugo@v1
        with:
          version: '0.154.5'
```

Bramka jakości — ten sam build plus serwer na czas audytu:

```yaml
      - uses: https://git.cierzniak.it/gitea-runner/actions/build-site-with-hugo@v1
        with:
          version: '0.154.5'
          serve-port: '8080'

      - run: pa11y-ci
```

`args` zastępuje **całą** listę flag, więc `--gc --minify` trzeba powtórzyć:

```yaml
      - uses: https://git.cierzniak.it/gitea-runner/actions/build-site-with-hugo@v1
        with:
          version: '0.154.5'
          args: --gc --minify --baseURL http://localhost:8080/
```

## Wejście

| Input | Wymagany | Domyślnie | Co to |
| --- | --- | --- | --- |
| `version` | tak | — | Wersja Hugo, bez wiodącego `v` (np. `0.154.5`) |
| `args` | nie | `--gc --minify` | Pełna lista argumentów `hugo` |
| `serve-port` | nie | — | Port, na którym wystawić `public/`. Pusty = nie serwuj |

Outputów nie ma.

Akcja buduje w katalogu roboczym joba i serwuje `public/` stamtąd — strona musi leżeć w głównym
katalogu repo. `http-server` przy `serve-port` pochodzi z obrazu joba; bramki w wizytówkach jadą
na `git.cierzniak.it/gitea-runner/node-chrome:24`.

## Wersja bez duplikatu

`version` jest wymagany, więc wpisany na sztywno w workflow dubluje wersję z `Dockerfile`
i rozjedzie się przy pierwszym bumpie obrazu. Odczytaj ją w jobie, zamiast przepisywać:

```yaml
      - name: Resolve Hugo version from Dockerfile
        id: hugo
        run: |
          version="$(sed -n 's|^FROM hugomods/hugo:exts-\([0-9][0-9.]*\) .*|\1|p' Dockerfile | head -1)"
          if [ -z "$version" ]; then
            echo "Nie udało się odczytać wersji Hugo z Dockerfile (zmienił się format linii FROM?)." >&2
            exit 1
          fi
          echo "version=$version" >> "$GITHUB_OUTPUT"

      - uses: https://git.cierzniak.it/gitea-runner/actions/build-site-with-hugo@v1
        with:
          version: ${{ steps.hugo.outputs.version }}
```

`Dockerfile` zostaje wtedy jedynym źródłem prawdy, a CI audytuje dokładnie tę wersję, która
jedzie na produkcję.

## Dlaczego tak

**Wersja przychodzi wyłącznie inputem, akcja nie zagląda do `Dockerfile`.** Odczyt po stronie
akcji wiązałby ją z konwencją budowania obrazu, której repo-konsument nie musi mieć — a to jest
jedyna rzecz, jakiej Hugo do zbudowania strony nie potrzebuje. Cenę (możliwy duplikat wersji)
zdejmuje wzorzec wyżej: `Dockerfile` dalej jest źródłem prawdy, tylko czyta go workflow.

**Bez kroku weryfikującego, czy `hugo version` zgadza się z inputem.** W lokalnych kopiach tej
akcji krok istniał, bo wersja pochodziła z `sed`-a i trzeba było sprawdzić, czy wyrażenie coś
złapało. Przy jawnym inpucie `peaceiris/actions-hugo` instaluje dokładnie żądaną wersję i wpycha
swój katalog na początek `PATH`, więc asercja porównywałaby input sam ze sobą. Zostaje wąski
przypadek: obraz joba z własnym Hugo, gdyby kiedyś wygrał `PATH` — job zbuduje się wtedy cicho
inną wersją. Jeśli to wystrzeli, krok wraca.

**`extended: true` na sztywno.** Wszystkie strony na tej instancji jadą na obrazach
`hugomods/hugo:exts-*`, czyli extended. Input dojdzie, gdy pojawi się konsument, który go
potrzebuje.

**`args` to jeden input z pełną listą flag.** Kto go podaje, przejmuje całość. Dwa inputy
(`minify: bool` plus `extra-args`) wymagałyby reguły, co się dzieje, gdy jeden zaprzecza
drugiemu — tu takiego stanu nie ma.

**Wyjście `http-server` idzie do `/tmp/http-server.log`, nie do potoku kroku.** Proces w tle
z otwartym stdout trzyma potok otwarty i runner czeka na EOF długo po zakończeniu audytu —
w `cierzniakowski-pl/wizytowka` przebieg 2145 wisiał na tym do timeoutu.

**Po starcie serwera leci polling `curl`, nie `sleep`.** Bramka, która ruszy przed serwerem,
pada na „no FCP", a ten komunikat czyta się jak problem ze stroną, nie z CI. Sześćdziesiąt prób
co sekundę, potem twardy błąd z numerem portu.