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

S
Description
No description provided
Readme
46 KiB