Update

.gitea/workflows/docker-build.yml

@@ -18,8 +18,22 @@ jobs:
       # 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.
+      # 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 die Cluster-interne ClusterIP 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 (docker-builder) laeuft im selben Kubernetes-Cluster wie
+      # Gitea und erreicht den Gitea-Service direkt, 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. Bei einer anderen ClusterIP/einem
+      # anderen Port hier anpassen (kubectl get svc -n <namespace> gitea).
+      REGISTRY_PUSH: 10.43.210.222:80
     steps:
       - name: Code auschecken
         uses: actions/checkout@v4
@@ -33,11 +47,17 @@ jobs:
 
       - 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."10.43.210.222:80"]
+              http = true
 
       - name: Bei der Gitea-Container-Registry anmelden
         uses: docker/login-action@v3
         with:
-          registry: ${{ env.REGISTRY }}
+          registry: ${{ env.REGISTRY_PUSH }}
           username: ${{ gitea.actor }}
           # GITEA_TOKEN hat aktuell KEIN Package-Write-Recht (Gitea-
           # Einschraenkung, Stand heute) — deshalb ein separates Personal
@@ -51,7 +71,7 @@ jobs:
         id: meta
         uses: docker/metadata-action@v5
         with:
-          images: ${{ env.REGISTRY }}/${{ steps.image.outputs.name }}
+          images: ${{ env.REGISTRY_PUSH }}/${{ steps.image.outputs.name }}
           tags: |
             type=raw,value=latest,enable={{is_default_branch}}
             type=sha,format=short
@@ -74,17 +94,15 @@ jobs:
 
       # 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 enthielt zusaetzlich
-      # next/react/sharp/alle devDependencies und wurde beim Push an die
-      # Gitea-Registry (hinter Cloudflare, ~100 MB Limit pro Layer) mit
-      # "413 Payload Too Large" abgewiesen. Wird vom Kubernetes-
-      # Migrations-Job verwendet, siehe k8s/04-migrate-job.yaml.
+      # 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 }}/${{ steps.image.outputs.name }}:migrate-${{ gitea.sha }}
+          tags: ${{ env.REGISTRY_PUSH }}/${{ steps.image.outputs.name }}:migrate-${{ gitea.sha }}
           cache-from: type=gha
           cache-to: type=gha,mode=max