# gitea-runner/actions Współdzielone composite actions do jobów Gitea Actions na `git.cierzniak.it`. Jedna akcja = jeden podkatalog. Repo może zostać prywatne — runner uwierzytelnia się przy pobieraniu akcji, patrz „Dostęp" niżej. ## Akcje | Akcja | Do czego | | --- | --- | | [`build-site-with-hugo`](build-site-with-hugo/) | Hugo w podanej wersji + build do `public/`, opcjonalny serwer dla bramek jakości | | [`pnpm-install`](pnpm-install/) | corepack + `pnpm install` z lockfile'a, opcjonalny cache store'a | | [`resolve-buildx-cache`](resolve-buildx-cache/) | `DOCKER_CACHE_*` z runnera → `driver-opts` i refy cache'a dla buildx | ## Jak używać Pełny URL w `uses:` i **tag**, nigdy `@main`: ```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 ``` Pełny URL jest konieczny, bo `DEFAULT_ACTIONS_URL` tej instancji wskazuje na GitHuba — `uses: gitea-runner/actions/...@v1` poleciałoby tam i padło. Przestawianie tego ustawienia na `self` jest odradzane przez dokumentację Gitei, bo wymusiłoby mirrorowanie lokalnie także `actions/checkout` i całej reszty. Tag zamiast gałęzi, ponieważ jedno repo obsługuje wiele pipeline'ów: push do `main` przy `@main` zmieniłby je wszystkie naraz. ## Dostęp Organizacja `gitea-runner` i to repo są **publiczne** — anonimowy `git ls-remote` po HTTPS działa, więc `act_runner` rozwiązuje `uses:` bez tokenu. Nowe repo-konsument nie wymaga żadnej konfiguracji po tej stronie; wystarczy poprawny URL w `uses:`. Gdyby repo kiedyś przeszło na prywatne albo organizacja na `limited`, wróci wymóg z czasów, gdy tak było: **Settings → Actions → General → collaborative owners** w tym repo, z *właścicielem* (organizacją albo użytkownikiem) konsumenta, nie pojedynczym repo. Runner pobiera wtedy akcje tokenem (`GoGitActionCache.Fetch` → `http.BasicAuth{Username: "token", Password: token}`), a bez nadanego dostępu job pada przy rozwiązywaniu `uses:`, jeszcze przed pierwszym krokiem akcji. Ustawienia nie ma w REST API — trzeba wyklikać. ## Wersjonowanie `vN` to **ruchomy** tag majora — poprawki i wstecznie zgodne zmiany przesuwają go na nowy commit, konsumenci nie ruszają swoich workflow. Zmiana łamiąca kontrakt (usunięty input, zmieniona semantyka outputu) dostaje `vN+1`, a stary tag zostaje tam, gdzie stał. Po przesunięciu tagu: `git tag -f vN && git push -f origin vN`. Runner rozwiązuje ref przy każdym jobie, więc konsumenci łapią zmianę bez żadnej akcji po swojej stronie — to samo zdanie czyta się też jako ostrzeżenie o zasięgu rażenia. ## Powiązane repo - [`gitea-runner/images`](https://git.cierzniak.it/gitea-runner/images) — obrazy bazowe jobów, ADR-y i przykłady workflow.