Files
Wabenhain/.gitea/workflows/docker-build.yml
T
Nick Szaunig 04da561380
Docker Image bauen und veroeffentlichen / build-and-push (push) Failing after 3m2s
fix: Gitea-Registry-URL nicht aus gitea.server_url ableiten
gitea.server_url ist in manchen Gitea-Versionen leer (go-gitea/gitea#23276)
und liefert selbst im Erfolgsfall eine volle URL mit https://-Schema statt
des fuer docker login/Image-Tags benoetigten reinen Hostnamens. Registry
jetzt fest als git.encry.de hinterlegt, k8s-Manifeste entsprechend
vorausgefuellt.
2026-08-18 01:36:03 +02:00

90 lines
3.7 KiB
YAML

name: Docker Image bauen und veroeffentlichen
# Laeuft bei jedem Push auf main (rollierendes ":latest" + ":<kurzer-commit-hash>")
# und bei Versions-Tags wie "v1.2.3" (zusaetzlich als eigener Tag). Manuell
# ueber "Run workflow" in der Gitea-Weboberflaeche ebenfalls startbar.
on:
push:
branches: [main]
tags: ["v*"]
workflow_dispatch:
jobs:
build-and-push:
runs-on: docker-builder
env:
# Fest hinterlegt statt ${{ gitea.server_url }}: das hat in manchen
# Gitea-Versionen einen Bug (leerer Wert im Runner, siehe
# go-gitea/gitea#23276) und liefert selbst wenn es funktioniert eine
# volle URL MIT "https://"-Schema — docker login/Image-Tags brauchen
# aber den reinen Hostnamen ohne Schema. Bei einem Umzug auf eine
# andere Gitea-Instanz hier anpassen.
REGISTRY: git.encry.de
steps:
- name: Code auschecken
uses: actions/checkout@v4
- name: Image-Namen in Kleinbuchstaben ermitteln
# OCI-Registries erlauben nur Kleinbuchstaben im Repository-Pfad;
# ${{ gitea.repository }} ("Owner/Repo") behaelt die Gross-/
# Kleinschreibung des Gitea-Repos bei.
id: image
run: echo "name=$(echo '${{ gitea.repository }}' | tr '[:upper:]' '[:lower:]')" >> "$GITEA_OUTPUT"
- name: Docker Buildx einrichten
uses: docker/setup-buildx-action@v3
- name: Bei der Gitea-Container-Registry anmelden
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ gitea.actor }}
# GITEA_TOKEN hat aktuell KEIN Package-Write-Recht (Gitea-
# Einschraenkung, Stand heute) — deshalb ein separates Personal
# Access Token als Repo-/Org-Secret REGISTRY_TOKEN anlegen
# (Scope: "package", Gitea-Einstellungen -> Anwendungen ->
# Access Tokens) und unter Repo-Einstellungen -> Actions ->
# Secrets als REGISTRY_TOKEN hinterlegen.
password: ${{ secrets.REGISTRY_TOKEN }}
- name: Metadaten (Tags/Labels) ermitteln
id: meta
uses: docker/metadata-action@v5
with:
images: ${{ env.REGISTRY }}/${{ steps.image.outputs.name }}
tags: |
type=raw,value=latest,enable={{is_default_branch}}
type=sha,format=short
type=semver,pattern={{version}}
# Laufzeit-Image (schlank, "output: standalone") — das ist das Image,
# das in Kubernetes tatsaechlich den Shop ausliefert (siehe
# k8s/app-deployment.yaml). Ein einzelnes Image traegt beide Prisma-
# Client-Varianten (Postgres + MySQL) und waehlt zur Laufzeit per
# DATABASE_PROVIDER, siehe src/lib/prisma.ts.
- name: Laufzeit-Image bauen und pushen
uses: docker/build-push-action@v6
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha
cache-to: type=gha,mode=max
# Migrations-Image: dieselbe Build-Stage wie oben, aber vor dem
# schlanken Runtime-Stage abgeschnitten (--target=builder) — enthaelt
# zusaetzlich die Prisma-CLI und tsx, die "pnpm db:push"/"pnpm db:seed"
# brauchen (im Laufzeit-Image bewusst NICHT enthalten, um es klein zu
# halten). Wird vom Kubernetes-Migrations-Job verwendet, siehe
# k8s/migrate-job.yaml.
- name: Migrations-Image bauen und pushen
uses: docker/build-push-action@v6
with:
context: .
target: builder
push: true
tags: ${{ env.REGISTRY }}/${{ steps.image.outputs.name }}:migrate-${{ gitea.sha }}
cache-from: type=gha
cache-to: type=gha,mode=max