actions/build-site-with-hugo/README.md

build-site-with-hugo

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

      - 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:

      - 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ć:

      - 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ć:

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