Only build/push Docker images on version tags, not every main push

Rebuilding and pushing all three images on every commit was unnecessary
churn - the workflow now triggers exclusively on v* tags, so :latest
tracks the last released version instead of the last commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.gitea/workflows/docker-build.yml

@@ -2,7 +2,6 @@ name: Docker-Images bauen und veröffentlichen
 
 on:
   push:
-    branches: [main]
     tags: ["v*"]
 
 env:
@@ -39,13 +38,10 @@ jobs:
           fi
 
           IMAGE="${{ env.REGISTRY }}/${{ env.IMAGE_NAMESPACE }}/${{ matrix.image }}"
-          TAGS="-t $IMAGE:latest -t $IMAGE:${{ gitea.sha }}"
-
-          # Bei einem Tag-Push (z.B. v0.1.0) zusätzlich mit dem Tag-Namen selbst versionieren,
-          # damit ein bestimmter Release pinnbar bleibt statt nur :latest/:<sha>.
-          if [ "${{ gitea.ref_type }}" = "tag" ]; then
-            TAGS="$TAGS -t $IMAGE:${{ gitea.ref_name }}"
-          fi
+          # Läuft nur noch bei einem Tag-Push (siehe `on:` oben) - :latest zeigt damit immer auf
+          # den zuletzt getaggten Release, nicht auf jeden main-Commit. :<sha> bleibt zusätzlich
+          # als exakter Build-Beleg, :<tag-name> (z.B. v0.1.3) zum gezielten Pinnen.
+          TAGS="-t $IMAGE:latest -t $IMAGE:${{ gitea.sha }} -t $IMAGE:${{ gitea.ref_name }}"
 
           docker buildx build \
             --push \

.htaccess

@@ -1,6 +1,15 @@
-# HTTPS erzwingen
+# HTTPS erzwingen - %{HTTPS} spiegelt nur die tatsächliche TLS-Verbindung zu Apache wider und lässt
+# sich über keine Env-Var vortäuschen (auch nicht per SetEnvIf/RewriteRule-E-Flag, siehe
+# omsorgWeb/docker/000-default.conf). Hinter einem TLS-terminierenden Reverse-Proxy (z.B. der
+# Docker-Deployment, siehe docker-compose.yml) ist %{HTTPS} deshalb IMMER "off", auch bei einer
+# echten HTTPS-Anfrage - ohne die zweite Bedingung würde das einen endlosen Redirect-Loop erzeugen
+# (Proxy leitet HTTPS-Request per HTTP weiter -> Apache hält es für HTTP -> redirected auf https://
+# -> Proxy nimmt HTTPS-Request an, leitet wieder per HTTP weiter -> ...). Die zweite Bedingung lässt
+# den Request durch, wenn der (vertrauenswürdige) Proxy per X-Forwarded-Proto bestätigt, dass die
+# ursprüngliche Anfrage bereits HTTPS war.
 RewriteEngine On
 RewriteCond %{HTTPS} !=on
+RewriteCond %{HTTP:X-Forwarded-Proto} !=https
 RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 
 # Verzeichnis-Listing verbieten

omsorgWeb/Dockerfile

@@ -14,6 +14,12 @@ RUN apt-get update \
 COPY omsorgWeb/docker/allow-htaccess.conf /etc/apache2/conf-available/allow-htaccess.conf
 RUN a2enconf allow-htaccess
 
+# Ersetzt die mitgelieferte Default-vhost (identisch, nur mit einer zusätzlichen Rewrite-Regel,
+# die den TLS-terminierenden Host-nginx davor erkennt - sonst redirected die root-.htaccess
+# endlos, siehe Datei-Kommentar. Muss im <VirtualHost>-Block selbst stehen, ein conf-enabled-Drop-in
+# außerhalb davon wird nicht mit der .htaccess desselben Pfads zusammengeführt.)
+COPY omsorgWeb/docker/000-default.conf /etc/apache2/sites-enabled/000-default.conf
+
 COPY omsorgWeb/ /var/www/html/
 COPY .htaccess /var/www/html/.htaccess
 

omsorgWeb/docker/000-default.conf

@@ -0,0 +1,22 @@
+<VirtualHost *:80>
+	ServerName omsorgweb
+	ServerAdmin webmaster@localhost
+	DocumentRoot /var/www/html
+
+	# Der Host-nginx terminiert TLS und proxied per HTTP an diesen Container (siehe
+	# docker-compose.yml) - ohne diese Regel weiß die root-.htaccess
+	# (`RewriteCond %{HTTPS} !=on` -> Redirect auf https://) nie, dass die ursprüngliche Anfrage
+	# HTTPS war, und redirected endlos (führt zu "Firefox kann nicht verbinden - Seite leitet
+	# falsch weiter" bzw. ERR_TOO_MANY_REDIRECTS). Per mod_rewrite-Trace verifiziert: das MUSS
+	# innerhalb dieses <VirtualHost>-Blocks stehen - weder eine Regel in conf-enabled/*.conf
+	# außerhalb jedes VirtualHost, noch eine in einem <Directory>-Block wird mit dem
+	# per-Directory-Regelsatz der .htaccess desselben Pfads zusammengeführt (beides per Trace
+	# ausprobiert, keins hat gewirkt - Apache vererbt Rewrite-Regeln standardmäßig nicht über
+	# Kontextgrenzen hinweg, siehe RewriteOptions Inherit in der mod_rewrite-Doku).
+	RewriteEngine On
+	RewriteCond "%{HTTP:X-Forwarded-Proto}" "=https"
+	RewriteRule ^ - [E=HTTPS:on]
+
+	ErrorLog ${APACHE_LOG_DIR}/error.log
+	CustomLog ${APACHE_LOG_DIR}/access.log combined
+</VirtualHost>