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 |
|---|---|
pnpm-install |
corepack + pnpm install z lockfile'a, opcjonalny cache store'a |
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:
- 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— obrazy bazowe jobów, ADR-y i przykłady workflow.