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" # To former for basic auth, fordi kun en kørende runner kan svare på, # hvilken Gitea tager imod. actions/checkout bruger x-access-token, og # det er den, økosystemet beviser virker; $GITHUB_ACTOR er reserven. # Løkken skriver, hvilken der blev godkendt — så ÉN kørsel besvarer # spørgsmålet, uanset om den ender grøn eller rød. Feedback-sløjfen her # går gennem en kø og et andet menneske; at bruge en hel runde på at få # ét bit at vide er for dyrt. godkendt= for bruger in x-access-token "$GITHUB_ACTOR"; do header="Authorization: Basic $(printf '%s:%s' "$bruger" "$TOKEN" | base64 | tr -d '\n')" if git -c http.extraheader="$header" fetch -q --depth=1 origin "$GITHUB_SHA"; then godkendt=$bruger break fi done if [ -z "$godkendt" ]; then echo "checkout: hverken x-access-token eller $GITHUB_ACTOR blev accepteret" exit 1 fi echo "checkout: godkendt som $godkendt" 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.)