From 544b51fda12ca7611e223618f51b93c0e5ca9d74 Mon Sep 17 00:00:00 2001 From: Nick Szaunig Date: Wed, 19 Aug 2026 04:04:21 +0200 Subject: [PATCH] Update --- .gitea/workflows/docker-build.yml | 36 +++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/.gitea/workflows/docker-build.yml b/.gitea/workflows/docker-build.yml index 5e29128..4a5d184 100644 --- a/.gitea/workflows/docker-build.yml +++ b/.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 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