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:
@@ -20,7 +19,7 @@ jobs:
             build_args: ""
           - image: omsorgapp
             dockerfile: omsorgapp/Dockerfile
-            build_args: "VITE_OMSORG_CORE_URL=${{ vars.OMSORG_CORE_PUBLIC_URL }}"
+            build_args: ""
           - image: omsorgweb
             dockerfile: omsorgWeb/Dockerfile
             build_args: ""
@@ -39,13 +38,10 @@ jobs:
           fi
 
           IMAGE="${{ env.REGISTRY }}/${{ env.IMAGE_NAMESPACE }}/${{ matrix.image }}"
-          TAGS="-t $IMAGE:latest -t $IMAGE:${{ gitea.sha }}"
+          # 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
-          # Bei einem Tag-Push (z.B. v0.1.0) zusätzlich mit dem Tag-Namen selbst versionieren,
+          # als exakter Build-Beleg, :<tag-name> (z.B. v0.1.3) zum gezielten Pinnen.
-          # damit ein bestimmter Release pinnbar bleibt statt nur :latest/:<sha>.
+          TAGS="-t $IMAGE:latest -t $IMAGE:${{ gitea.sha }} -t $IMAGE:${{ gitea.ref_name }}"
-          if [ "${{ gitea.ref_type }}" = "tag" ]; then
-            TAGS="$TAGS -t $IMAGE:${{ gitea.ref_name }}"
-          fi
 
           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

docker-compose.yml

@@ -1,12 +1,54 @@
 name: omsorg
 
-# WICHTIG (der fehleranfälligste Punkt in diesem Setup):
+# Zieht fertig gebaute Images aus der Gitea-Registry (siehe .gitea/workflows/docker-build.yml),
-# - omsorgapp.build.args.VITE_OMSORG_CORE_URL muss die vom BROWSER erreichbare Adresse von
+# baut hier bewusst NICHT lokal - die Dockerfiles in omsorgCore/, omsorgapp/, omsorgWeb/ sind
-#   omsorgcore sein (hier: der auf dem Host published Port), NICHT der interne Compose-DNS-Name -
+# weiterhin da, werden aber nur noch von der CI verwendet. Vor `docker compose pull`/`up` einmal
-#   Vite bäckt diese URL zur Build-Zeit in den JS-Bundle ein (siehe omsorgapp/src/api/config.js).
+# `docker login git.omsorg-pflegedienste.de` auf dem Server ausführen, falls die Images/Packages
-# - omsorgweb.environment.OMSORG_CORE_URL ist dagegen der interne Servicename (http://omsorgcore:8080),
+# nicht öffentlich lesbar sind. Über OMSORG_IMAGE_TAG lässt sich ein bestimmter Versions-Tag
-#   da PHP dort serverseitig per cURL aufruft (kein Browser-Kontext), siehe
+# pinnen (z.B. `OMSORG_IMAGE_TAG=v0.1.0 docker compose up -d`), Default ist `latest`.
-#   omsorgWeb/docker/bootstrap-config.php.
+#
+# omsorgCore bekommt eine eigene Subdomain (core.omsorg-pflegedienste.de), nicht denselben
+# Hostnamen wie omsorgapp - Begründung: omsorgWeb (beide mitarbeiter-app*-Apps) braucht ohnehin nie
+# Browser-Zugriff auf omsorgCore (PHP ruft serverseitig per cURL auf, siehe
+# omsorgWeb/docker/bootstrap-config.php/OMSORG_CORE_URL unten), nur omsorgapp tut das - eine eigene
+# Subdomain macht die API trotzdem unabhängig von omsorgapps Hosting adressierbar (künftige
+# Clients, Doku, Swagger) und ist nicht unsicherer als Pfad-basiertes Proxying: in beiden Fällen
+# ist omsorgCore nur über 127.0.0.1 erreichbar (Port-Mapping unten), nie direkt öffentlich.
+# Browser-seitiges Cross-Origin läuft über CORS + HttpOnly-Cookie mit credentials:"include" (siehe
+# omsorgCore/CLAUDE.md, Abschnitt "Auth-Flow") - dafür muss Cors__AllowedOrigins__0 unten exakt
+# der Origin von omsorgapp entsprechen (https://app.omsorg-pflegedienste.de).
+#
+# Nginx-Server-Block für die neue Subdomain (analog zum bestehenden app.omsorg-pflegedienste.de-
+# Block, eigenes Zertifikat z.B. per `certbot --nginx -d core.omsorg-pflegedienste.de`):
+#
+#   server {
+#       server_name core.omsorg-pflegedienste.de;
+#       location / {
+#           proxy_pass http://127.0.0.1:8080;
+#           proxy_http_version 1.1;
+#           proxy_set_header Host $host;
+#           proxy_set_header X-Real-IP $remote_addr;
+#           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+#           proxy_set_header X-Forwarded-Proto $scheme;
+#       }
+#       listen 443 ssl; # managed by Certbot
+#       ssl_certificate /etc/letsencrypt/live/core.omsorg-pflegedienste.de/fullchain.pem;
+#       ssl_certificate_key /etc/letsencrypt/live/core.omsorg-pflegedienste.de/privkey.pem;
+#       include /etc/letsencrypt/options-ssl-nginx.conf;
+#       ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
+#   }
+#
+# Alle persistenten Daten liegen bewusst als Bind-Mounts unter /root/data/ auf der Platte (keine
+# benannten Docker-Volumes) - vor dem ersten `docker compose up` einmalig anlegen:
+#   mkdir -p /root/data/postgres /root/data/omsorgcore/documents \
+#     /root/data/omsorgweb/{uploads,downloads,fortbildung-materials,avatars,data}
+# Postgres läuft im Container als uid 999 (nicht root) - /root/data/postgres muss dieser uid
+# gehören, sonst schlägt der Start mit einem Permission-Fehler fehl:
+#   chown -R 999:999 /root/data/postgres
+#
+# mitarbeiter-app-legacy (Teil des omsorgweb-Images) ist Legacy-Code und braucht eigentlich MySQL -
+# bewusst kein MySQL-Dienst mehr hier, die Legacy-App bleibt dadurch ohne DB-Anbindung (siehe
+# omsorgWeb/CLAUDE.md - mitarbeiter-app-legacy wird nicht mehr weiterentwickelt).
 
 services:
   postgres:
@@ -16,32 +58,15 @@ services:
       POSTGRES_USER: omsorg_core
       POSTGRES_PASSWORD: omsorg_core_dev_password
     volumes:
-      - postgres_data:/var/lib/postgresql/data
+      - /root/data/postgres:/var/lib/postgresql/data
     healthcheck:
       test: ["CMD-SHELL", "pg_isready -U omsorg_core"]
       interval: 5s
       timeout: 5s
       retries: 10
 
-  mysql:
-    image: mysql:8.0
-    environment:
-      MYSQL_DATABASE: omsorg_web
-      MYSQL_USER: omsorg_web
-      MYSQL_PASSWORD: omsorg_web_dev_password
-      MYSQL_ROOT_PASSWORD: omsorg_web_root_dev_password
-    volumes:
-      - mysql_data:/var/lib/mysql
-    healthcheck:
-      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
-      interval: 5s
-      timeout: 5s
-      retries: 10
-
   omsorgcore:
-    build:
+    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgcore:${OMSORG_IMAGE_TAG:-latest}
-      context: .
-      dockerfile: omsorgCore/Dockerfile
     depends_on:
       postgres:
         condition: service_healthy
@@ -49,53 +74,39 @@ services:
       ASPNETCORE_ENVIRONMENT: Development
       ConnectionStrings__OmsorgCore: "Host=postgres;Port=5432;Database=omsorg_core;Username=omsorg_core;Password=omsorg_core_dev_password"
       Jwt__Secret: "CHANGE_ME_LOCAL_DEV_SECRET_MIN_32_CHARS_LONG"
-      Cors__AllowedOrigins__0: "http://localhost:5173"
+      Cors__AllowedOrigins__0: "https://app.omsorg-pflegedienste.de"
     ports:
-      - "8080:8080"
+      # Nur auf dem Host erreichbar (für den Reverse-Proxy oben), nie auf der öffentlichen
+      # Schnittstelle - matcht das 127.0.0.1:5173-Muster im bestehenden Host-nginx.
+      - "127.0.0.1:8080:8080"
     volumes:
-      - omsorgcore_documents:/app/App_Data/documents
+      - /root/data/omsorgcore/documents:/app/App_Data/documents
 
   omsorgapp:
-    build:
+    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgapp:${OMSORG_IMAGE_TAG:-latest}
-      context: .
+    environment:
-      dockerfile: omsorgapp/Dockerfile
+      # Vom BROWSER erreichbare Adresse von omsorgCore - der Container-Entrypoint schreibt das
-      args:
+      # zur Laufzeit in env-config.js (siehe omsorgapp/docker-entrypoint.sh/src/api/config.js),
-        VITE_OMSORG_CORE_URL: "http://localhost:8080"
+      # kein Rebuild bei einer geänderten Backend-URL nötig.
+      OMSORG_CORE_URL: "https://core.omsorg-pflegedienste.de"
     ports:
-      - "5173:80"
+      # Nur auf dem Host, wie omsorgcore oben - der Host-nginx proxied bereits 127.0.0.1:5173.
+      - "127.0.0.1:5173:80"
     depends_on:
       - omsorgcore
 
   omsorgweb:
-    build:
+    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgweb:${OMSORG_IMAGE_TAG:-latest}
-      context: .
-      dockerfile: omsorgWeb/Dockerfile
     depends_on:
-      mysql:
-        condition: service_healthy
       omsorgcore:
         condition: service_started
     environment:
-      DB_HOST: mysql
-      DB_NAME: omsorg_web
-      DB_USER: omsorg_web
-      DB_PASSWORD: omsorg_web_dev_password
       OMSORG_CORE_URL: "http://omsorgcore:8080"
     ports:
       - "8081:80"
     volumes:
-      - web_uploads:/var/www/html/mitarbeiter-app-legacy/uploads
+      - /root/data/omsorgweb/uploads:/var/www/html/mitarbeiter-app-legacy/uploads
-      - web_downloads:/var/www/html/mitarbeiter-app-legacy/downloads
+      - /root/data/omsorgweb/downloads:/var/www/html/mitarbeiter-app-legacy/downloads
-      - web_fortbildung:/var/www/html/mitarbeiter-app-legacy/fortbildung-materials
+      - /root/data/omsorgweb/fortbildung-materials:/var/www/html/mitarbeiter-app-legacy/fortbildung-materials
-      - web_avatars:/var/www/html/mitarbeiter-app-legacy/assets/avatars
+      - /root/data/omsorgweb/avatars:/var/www/html/mitarbeiter-app-legacy/assets/avatars
-      - web_data:/var/www/html/mitarbeiter-app-legacy/data
+      - /root/data/omsorgweb/data:/var/www/html/mitarbeiter-app-legacy/data
-
-volumes:
-  postgres_data:
-  mysql_data:
-  omsorgcore_documents:
-  web_uploads:
-  web_downloads:
-  web_fortbildung:
-  web_avatars:
-  web_data:

omsorgWeb/Dockerfile

@@ -14,12 +14,26 @@ 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
 
 RUN chmod +x /var/www/html/docker/docker-entrypoint.sh \
-    # Schreibbare Verzeichnisse für Datei-Uploads zur Laufzeit (siehe docker-compose.yml-Volumes) -
+    # Schreibbare Verzeichnisse für Datei-Uploads zur Laufzeit (siehe docker-compose.yml-Volumes).
-    # Besitzer auf den Apache-User setzen, damit PHP dort schreiben kann.
+    # Existieren im Repo NICHT zwingend (Root-.gitignore schließt sie komplett aus - lokal hatten
+    # sie bei mir Testdateien, ein frischer CI-Checkout hat sie gar nicht) - deshalb erst anlegen,
+    # dann Besitzer auf den Apache-User setzen, damit PHP dort schreiben kann.
+    && mkdir -p \
+        /var/www/html/mitarbeiter-app-legacy/uploads \
+        /var/www/html/mitarbeiter-app-legacy/downloads \
+        /var/www/html/mitarbeiter-app-legacy/fortbildung-materials \
+        /var/www/html/mitarbeiter-app-legacy/assets/avatars \
+        /var/www/html/mitarbeiter-app-legacy/data \
     && chown -R www-data:www-data \
         /var/www/html/mitarbeiter-app-legacy/uploads \
         /var/www/html/mitarbeiter-app-legacy/downloads \

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>

omsorgapp/Dockerfile

@@ -13,9 +13,10 @@ RUN npm ci
 
 COPY omsorgapp/ .
 
-# Vite bäckt import.meta.env.VITE_OMSORG_CORE_URL (src/api/config.js) zur Build-Zeit ein - kein
+# Fallback für lokale/CI-Builds ohne Container (npm run dev/build) - im Container selbst
-# Runtime-Wert. Default passt zum docker-compose.yml-Setup, für einen echten Deploy überschreibt
+# entscheidet ausschließlich die Laufzeit-Env-Var OMSORG_CORE_URL (siehe docker-entrypoint.sh),
-# CI das per --build-arg mit der öffentlich erreichbaren omsorgCore-URL.
+# da dieses Image aus der Registry gezogen und per docker-compose.yml konfiguriert wird, nicht
+# pro Zielumgebung neu gebaut (siehe src/api/config.js).
 ARG VITE_OMSORG_CORE_URL=http://localhost:8080
 ENV VITE_OMSORG_CORE_URL=$VITE_OMSORG_CORE_URL
 RUN npm run build
@@ -23,4 +24,7 @@ RUN npm run build
 FROM nginx:1.27-alpine AS runtime
 COPY --from=build /app/dist /usr/share/nginx/html
 COPY omsorgapp/nginx.conf /etc/nginx/conf.d/default.conf
+COPY omsorgapp/docker-entrypoint.sh /docker-entrypoint.sh
+RUN chmod +x /docker-entrypoint.sh
 EXPOSE 80
+ENTRYPOINT ["/docker-entrypoint.sh"]

omsorgapp/docker-entrypoint.sh

@@ -0,0 +1,11 @@
+#!/bin/sh
+set -eu
+
+# Schreibt die Laufzeit-Backend-Adresse in env-config.js, bevor nginx startet - siehe
+# src/api/config.js. OMSORG_CORE_URL kommt aus docker-compose.yml, muss vom BROWSER erreichbar
+# sein (nicht der interne Compose-Servicename), z.B. https://core.omsorg-pflegedienste.de.
+cat > /usr/share/nginx/html/env-config.js <<EOF
+window.__OMSORG_ENV__ = { OMSORG_CORE_URL: "${OMSORG_CORE_URL:-}" };
+EOF
+
+exec nginx -g "daemon off;"

omsorgapp/index.html

@@ -1 +1 @@
-<!doctype html><html lang="de"><head><meta charset="UTF-8"/><meta name="viewport" content="width=device-width, initial-scale=1.0"/><title>Omsorg Business Controls Pro</title></head><body><div id="root"></div><script type="module" src="/src/main.jsx"></script></body></html>
+<!doctype html><html lang="de"><head><meta charset="UTF-8"/><meta name="viewport" content="width=device-width, initial-scale=1.0"/><title>Omsorg Business Controls Pro</title></head><body><div id="root"></div><script src="/env-config.js"></script><script type="module" src="/src/main.jsx"></script></body></html>

omsorgapp/public/env-config.js

@@ -0,0 +1,4 @@
+// Dev-Default (Vite serviert alles unter public/ unverändert unter /) - im Docker-Image wird
+// diese Datei vom Entrypoint (docker-entrypoint.sh) aus der OMSORG_CORE_URL-Env-Var überschrieben,
+// siehe src/api/config.js.
+window.__OMSORG_ENV__ = {};

omsorgapp/src/api/config.js

@@ -1,4 +1,8 @@
 // Einzige Stelle im Projekt, die die Adresse von omsorgCore kennt.
-// Default passt zum lokalen `dotnet run --project src/OmsorgCore.Api` (http-Profil, Port 5245),
+// Reihenfolge: 1) Laufzeit-Konfiguration (window.__OMSORG_ENV__, aus env-config.js - vom
-// überschreibbar per Vite-Env-Variable (VITE_OMSORG_CORE_URL) für andere Umgebungen.
+// nginx-Entrypoint im Container aus der OMSORG_CORE_URL-Env-Var generiert, siehe
-export const API_BASE = import.meta.env.VITE_OMSORG_CORE_URL || "http://localhost:5245";
+// omsorgapp/docker-entrypoint.sh) - so lässt sich die Backend-Adresse rein über
+// docker-compose.yml setzen, ohne das Image neu zu bauen. 2) Vite-Build-Zeit-Env
+// (VITE_OMSORG_CORE_URL, für `npm run dev`/lokale Builds ohne Container). 3) localhost-Default.
+export const API_BASE =
+  window.__OMSORG_ENV__?.OMSORG_CORE_URL || import.meta.env.VITE_OMSORG_CORE_URL || "http://localhost:5245";