Build: harte Zeitgrenzen für Tests (90 s je Test, 15 min gesamt, Job 30 min), Tests ausführlich protokollieren

Ein Test hing auf dem Runner fast eine Stunde in einem Systemaufruf, wo der Tk-Watchdog der GUI-Tests
nicht greift. pytest-timeout bricht ab und gibt den Aufrufstapel aus.

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

.gitea/workflows/windows-build.yml

@@ -14,6 +14,7 @@ jobs:
   windows-exe:
     # Label ggf. an euren Runner anpassen (Runner braucht Docker; Wine steckt im Container-Image).
     runs-on: ubuntu-latest
+    timeout-minutes: 30   # normal ca. 5 Minuten – ein Hänger darf den Runner nicht stundenlang belegen
     container:
       image: tobix/pywine:3.12
     env:

build/build_windows.sh

@@ -26,7 +26,8 @@ $PY -m pip install --disable-pip-version-check -q -r requirements-dev.txt
 
 echo "== Tests inkl. Oberfläche (Windows-Python unter Wine) =="
 # PROVTOOL_GUI_TESTS=1: fehlt der Bildschirm, ist das ein Fehler (nicht „übersprungen“)
-PROVTOOL_GUI_TESTS=1 $PY -m pytest -q -p no:cacheprovider
+# -v: im Log ist live sichtbar, welcher Test läuft; timeout: Obergrenze für alle Tests zusammen
+PROVTOOL_GUI_TESTS=1 timeout 900 $PY -m pytest -v -p no:cacheprovider
 
 echo "== Version =="
 VERSION=$($PY build/version_info.py | tr -d '\r')

pytest.ini

@@ -1,3 +1,8 @@
 [pytest]
 pythonpath = .
 testpaths = tests
+# Kein Test darf den Build blockieren: nach 90 s wird abgebrochen und der Aufrufstapel aller
+# Threads ausgegeben (zeigt, wo es hängt – auch in Windows-Systemaufrufen, wo der Tk-Watchdog
+# der GUI-Tests nicht greift).
+timeout = 90
+timeout_method = thread

requirements-dev.txt

@@ -1,3 +1,4 @@
 -r requirements.txt
 pytest==8.3.3
 pyinstaller==6.11.1
+pytest-timeout==2.3.1