Kristian Wind
c930e6163e
DEFAULT_ACTIONS_URL står ikke i app.ini på gitea.nolimit.dk, og standarden er github.com. Et `uses: actions/checkout@v4` i et Gitea-workflow bliver derfor hentet fra GitHub, hver gang, også når både koden, runneren og registret er vores egne — så et workflow, der bruger markedspladsen, ser uafhængigt ud uden at være det. Begge Gitea-workflows er skrevet om uden `uses:`. Værktøjskæden kommer fra jobbets container, hvilket er det, setup-go ellers ville bruge et trin på; checkout, login, metadata og buildx er de rå kommandoer, handlingerne pakker. Det, der ikke fulgte med: rapporten fra en fejlet e2e-kørsel. upload-artifact har ingen `run:`-form, så grunden står i loggen frem for i en zip. Udgivelsen fik samtidig en rettelse, GitHub-udgaven ikke har: en forudgivelse (v1.4.2-rc1) får kun sit eget mærkat. At lade en rc overskrive :latest eller :1 ville sende den ud til alle, der troede, de fulgte det stabile spor. Issue-skabeloner i .gitea/ for sig: Gitea kræver `about`, hvor GitHub skriver `description`, og afviser en skabelon uden.
109 lines
4.7 KiB
YAML
109 lines
4.7 KiB
YAML
name: Release
|
|
|
|
# Samme udløser som GitHub-workflowet: et semver-tag, og ikke andet.
|
|
#
|
|
# Gitea Actions læser samme format som GitHub Actions, men det er *ikke* det
|
|
# samme sted. Filen ligger derfor for sig frem for at være delt: der er intet
|
|
# `secrets.GITHUB_TOKEN`, registret er et andet, og der er ingen Releases-side at
|
|
# skrive til. En delt fil ville være fire betingede led, der hver kun gælder ét
|
|
# af de to steder.
|
|
#
|
|
# Og som i ci.yml: ingen `uses:`. Handlinger hentes fra github.com, så længe
|
|
# DEFAULT_ACTIONS_URL ikke er sat — se den lange forklaring der.
|
|
on:
|
|
push:
|
|
tags: ["v[0-9]+.[0-9]+.[0-9]+*"]
|
|
|
|
jobs:
|
|
image:
|
|
name: Build and publish image
|
|
# `ubuntu-latest` er runnerens egen etiket (`ovh-1`, docker-mode). Ingen
|
|
# `container:`: jobbet skal bruge docker-klienten og buildx, og dem har
|
|
# runnerens image.
|
|
runs-on: ubuntu-latest
|
|
env:
|
|
REGISTRY: gitea.nolimit.dk
|
|
steps:
|
|
- name: Checkout
|
|
env:
|
|
TOKEN: ${{ secrets.GITEA_TOKEN }}
|
|
run: |
|
|
set -eu
|
|
git config --global --add safe.directory '*'
|
|
git init -q .
|
|
git remote add origin "$GITHUB_SERVER_URL/$GITHUB_REPOSITORY.git"
|
|
git -c http.extraheader="Authorization: Basic $(printf '%s:%s' "$GITHUB_ACTOR" "$TOKEN" | base64 | tr -d '\n')" \
|
|
fetch -q --depth=1 origin "$GITHUB_SHA"
|
|
git checkout -q FETCH_HEAD
|
|
|
|
# setup-qemu-action i rå form. Uden den bygger buildx kun værtens egen
|
|
# arkitektur, og arm64 er ikke valgfrit: et hjemmelab er lige så tit en
|
|
# Raspberry Pi eller en Apple silicon-VM som en x86-kasse.
|
|
- name: Emulation for the other architecture
|
|
run: docker run --privileged --rm tonistiigi/binfmt --install arm64,amd64
|
|
|
|
- name: Builder
|
|
run: docker buildx create --use --name release-verdande 2>/dev/null || docker buildx use release-verdande
|
|
|
|
# `GITEA_TOKEN` er automatisk til stede i et Actions-job og har lov at
|
|
# skrive pakker for den, der ejer repoet. Ingen hemmelighed at sætte op.
|
|
# --password-stdin frem for --password: det sidste ville stå i processens
|
|
# kommandolinje, som enhver på maskinen kan læse.
|
|
- name: Log in to the registry
|
|
env:
|
|
TOKEN: ${{ secrets.GITEA_TOKEN }}
|
|
run: printf '%s' "$TOKEN" | docker login "$REGISTRY" -u "$GITHUB_ACTOR" --password-stdin
|
|
|
|
# metadata-action i rå form.
|
|
#
|
|
# v1.4.2 udgiver 1.4.2, 1.4, 1 og latest — så en rune, der er bundet til
|
|
# :1, får rettelser uden nogensinde at krydse et hovedversionsskifte.
|
|
#
|
|
# En forudgivelse (v1.4.2-rc1) får KUN sit eget nøjagtige mærkat. At lade
|
|
# en rc overskrive :latest eller :1 ville sende den ud til alle, der troede
|
|
# de fulgte det stabile spor — og mærkatmønsteret ovenfor lukker dem ind.
|
|
- name: Work out the tags
|
|
id: tags
|
|
run: |
|
|
set -eu
|
|
version=${GITHUB_REF_NAME#v}
|
|
image="$REGISTRY/$GITHUB_REPOSITORY"
|
|
args="--tag $image:$version"
|
|
case "$version" in
|
|
*-*) echo "Forudgivelse: kun $version." ;;
|
|
*)
|
|
minor=${version%.*}
|
|
major=${version%%.*}
|
|
args="$args --tag $image:$minor --tag $image:$major --tag $image:latest"
|
|
;;
|
|
esac
|
|
echo "args=$args" >> "$GITHUB_OUTPUT"
|
|
echo "Mærkater: $args"
|
|
|
|
- name: Build and push
|
|
run: |
|
|
set -eu
|
|
docker buildx build \
|
|
--platform linux/amd64,linux/arm64 \
|
|
--push \
|
|
${{ steps.tags.outputs.args }} \
|
|
--build-arg "VERSION=$GITHUB_REF_NAME" \
|
|
--label "org.opencontainers.image.source=$GITHUB_SERVER_URL/$GITHUB_REPOSITORY" \
|
|
--label "org.opencontainers.image.version=$GITHUB_REF_NAME" \
|
|
--label "org.opencontainers.image.revision=$GITHUB_SHA" \
|
|
--label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
|
|
.
|
|
# Ingen `cache-from: type=gha`. act_runner har en cache-tjeneste, der
|
|
# svarer på det navn, men den er ikke prøvet her, og en kold bygning,
|
|
# der tager nogle minutter længere, er billigere end en udgivelse, der
|
|
# fejler på noget, som ikke har med bygningen at gøre.
|
|
|
|
# Ingen Release oprettes.
|
|
#
|
|
# GitHub-workflowet laver en Release, fordi opdateringsnotitsen i appen læser
|
|
# `releases/latest` derfra. Gitea har sit eget Releases-begreb, men notitsen
|
|
# peger på GitHub — så en release her ville ingen læse. Skal notitsen flyttes
|
|
# med, er det `internal/update`, der skal have en ny adresse, og det er en
|
|
# ændring for sig. (Bemærk også, at GitHub-udgavens softprops-handling taler
|
|
# mod api.github.com og ikke kan genbruges her.)
|