Tests im Dockerfile statt über setup-python

actions/setup-python@v5 lädt seine Runtime von GitHub-Releases und
scheitert auf dem Gitea-Runner - der Lauf brach vor dem Deploy ab.

Die Tests laufen jetzt in einer eigenen Dockerfile-Stufe, die der
Workflow mit --target test aufruft. Damit gilt für sie dieselbe
Python-Version und derselbe Paketstand wie für die Produktion, und der
Schritt braucht nichts außer dem Docker-Daemon, den der Runner ohnehin
nutzt. Ein Bind-Mount des Workspace wäre keine Option gewesen: der liegt
im Job-Container, der Pfad zeigt auf dem Host ins Leere.

Die Teststufe hängt nicht am finalen Image und wird beim Deploy-Build
übersprungen.

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

.dockerignore

@@ -2,7 +2,6 @@
 .gitea
 .venv
 data
-tests
 __pycache__
 *.pyc
 *.log

.gitea/workflows/deploy.yml

@@ -16,15 +16,13 @@ jobs:
         with:
           github-server-url: http://gitea:3000
 
-      - uses: actions/setup-python@v5
+      # Kein setup-python: die Action laedt ihre Runtime von GitHub-Releases
-        with:
+      # und scheitert auf dem Gitea-Runner. Stattdessen laufen die Tests in
-          python-version: '3.12'
+      # einer eigenen Stufe des Dockerfiles - gegen dieselbe Python-Version
-
+      # und dieselben Pakete wie die Produktion. Ein roter Lauf bricht hier
-      - name: Abhaengigkeiten installieren
+      # ab, bevor irgendetwas auf dem Server angefasst wird.
-        run: pip install -r requirements-dev.txt
-
       - name: Tests
-        run: pytest -q
+        run: docker build --target test .
 
       - name: Tag ermitteln
         run: echo "IMAGE_TAG=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV

Dockerfile

@@ -1,11 +1,26 @@
 # Abhaengigkeiten in ein venv bauen, damit der Compiler-Ballast nicht ins
 # fertige Image wandert.
 FROM python:3.12-slim AS build
+WORKDIR /app
 RUN python -m venv /opt/venv
 ENV PATH="/opt/venv/bin:$PATH"
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 
+# Testlauf gegen dieselbe Python-Version und dieselben Pakete wie die
+# Produktion. Die Stufe haengt nicht am finalen Image und wird bei einem
+# normalen Build uebersprungen; der Workflow ruft sie mit --target test auf.
+FROM build AS test
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends libglib2.0-0 \
+    && rm -rf /var/lib/apt/lists/*
+COPY requirements-dev.txt .
+RUN pip install --no-cache-dir -r requirements-dev.txt
+COPY app ./app
+COPY static ./static
+COPY tests ./tests
+RUN pytest -q
+
 FROM python:3.12-slim
 ENV PYTHONUNBUFFERED=1 \
     PYTHONDONTWRITEBYTECODE=1 \