Lars
c69edc6952
All checks were successful
Deploy Development / deploy (push) Successful in 38s
Test Suite / pytest-backend (push) Successful in 36s
Test Suite / lint-backend (push) Successful in 0s
Test Suite / build-frontend (push) Successful in 12s
Test Suite / k6 /health Baseline (push) Successful in 33s
Test Suite / playwright-tests (push) Successful in 1m5s
- Introduced a new job `k6-health-baseline` in the Gitea CI workflow to run health checks independently from Playwright tests, enhancing clarity and organization. - Updated documentation to reflect the changes in the CI pipeline, specifying the execution order and purpose of each job. - Adjusted environment variables and health check logic for both development and production modes, ensuring accurate testing conditions.
1.1 KiB
1.1 KiB
k6 – Health-Baseline (Phase 0)
Parallele GETs auf /health – ohne Auth, geeignet für Dev/Prod hinter dem gleichen Proxy wie die App.
CI / Deploy: In .gitea/workflows/test.yml eigener Job k6-health-baseline (nur Checkout + /health-Wartezeit + k6). Playwright läuft parallel/im selben Workflow im Job playwright-tests — ohne k6. Gleiche BASE_URL-Logik (Dev oder Prod nach workflow_run).
Voraussetzung
Aufruf Beispiel
# Windows PowerShell
$env:BASE_URL="https://dev.shinkan.jinkendo.de"
k6 run scripts/load/k6-health-baseline.js
# Linux / macOS
BASE_URL=https://dev.shinkan.jinkendo.de k6 run scripts/load/k6-health-baseline.js
Architektur: Der Workflow lädt linux-amd64 oder linux-arm64 je nach uname -m (z. B. Gitea-Runner auf Raspberry Pi 5).
Auswertung
In der k6-Zusammenfassung http_req_duration → p(95) in BASELINE_SNAPSHOT.md eintragen.
Schwellwerte sind bewusst locker (p95 < 3s); bei Fehlschlag Proxy, Netz oder Backend prüfen.