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. Nur noch fuer Doku/OCI-Labels
      # relevant — der eigentliche Push laeuft ueber REGISTRY_PUSH (s.u.),
      # Kubernetes zieht die Images weiterhin ueber diesen Hostnamen.
      REGISTRY: git.encry.de
      # Gitea-Registry-Push laeuft ueber den Cluster-internen Service-Namen
      # statt git.encry.de: Docker-Registry-Blob-Uploads (PUT) vertragen sich
      # nicht mit dem Cloudflare-Proxy vor git.encry.de — "413 Payload Too
      # Large" auch bei kleinen Layern, unabhaengig von der eigentlichen
      # Groesse. Der Runner-Pod (gitea-runner, Namespace "gitea") erreicht
      # den Gitea-Service direkt ueber Kubernetes-DNS ("gitea:80" — siehe
      # dessen eigene GITEA_INSTANCE_URL-Env, die denselben Hostnamen nutzt),
      # ohne ueber Cloudflare zu hairpinnen. Push und Pull landen im selben
      # Registry-Pfad (Owner/Repo:Tag) — der Hostname ist nur die Verbindung,
      # nicht Teil des gespeicherten Images, daher bleibt der Pull in den
      # k8s-Manifesten unveraendert ueber git.encry.de.
      REGISTRY_PUSH: gitea:80
    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
        with:
          # REGISTRY_PUSH ist Klartext-HTTP (Gitea-Service intern ohne TLS)
          # statt HTTPS — BuildKit lehnt das ohne diese Freigabe ab.
          config-inline: |
            [registry."gitea:80"]
              http = true

      - name: Bei der Gitea-Container-Registry anmelden
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY_PUSH }}
          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_PUSH }}/${{ 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: eigene schlanke Stage (nur Prisma-CLI/tsx + ein
      # paar Laufzeit-Pakete, siehe Dockerfile-Kommentar bei "AS migrator")
      # statt der vollen builder-Stage, die zusaetzlich next/react/sharp/alle
      # devDependencies enthielt. Wird vom Kubernetes-Migrations-Job
      # verwendet, siehe k8s/04-migrate-job.yaml.
      - name: Migrations-Image bauen und pushen
        uses: docker/build-push-action@v6
        with:
          context: .
          target: migrator
          push: true
          tags: ${{ env.REGISTRY_PUSH }}/${{ steps.image.outputs.name }}:migrate-${{ gitea.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max