Testing and CI

Generated from README.md in the repository. Edit it there; this wiki is rebuilt on every change.

CI/CD and quality gates

Every push and pull request runs CI in two stages. Every check is required on main, so a pull request cannot be merged until all of them pass.

Stage 1, the gate (in parallel):

Gate	What it checks
Lint	Python syntax and undefined names (ruff), shell scripts parse, both Compose files valid, no em dashes
Secret scan	gitleaks over the full Git history
Security scans	Bandit (no unreviewed medium or high finding), pip-audit (no dependency with a known vulnerability), a check that no SQL is built from request input; CodeQL for Python and JavaScript runs alongside
Data lake replication	tools/lake_e2e.py on two real MariaDB servers: replication, purges that never reach the lake, hot retention, refusal while replication is stopped, catch-up, and lake-init run twice
Unit tests	the whole pytest suite on Python 3.11, 3.12 and 3.13 (including the API's authentication, permission, injection-fuzzing and no-secrets tests), plus the 300-node performance budget; fails unless every test passed, none was skipped, at least 170 ran (tools/test_gate.py) and coverage is at least 74 percent
Browser UI	tools/ui_test.py in Chromium: 1500 nodes, every page on phone, tablet, laptop and desktop sizes and at 67 to 200 percent zoom (nothing outside its card, no sideways scroll, no broken words, no script errors), then the interactions: filters, Select All, bulk actions, dialogs, Recycle Bin, VPN filters, stats export, saved settings, fleet terminal and a real SSH terminal on a Pi Fleet Emulator node; at least 375 checks must run. Failure screenshots are kept as an artifact

Each job writes its counts to the run's summary page.

Stage 2, only when the whole gate passed:

Gate	What it checks
Image	amd64 and arm64 builds; non-root user, no .env, databases, keys or secrets in layers or history; refuses to start without keys; Trivy vulnerability scan to the Security tab
Sandbox E2E	The full sandbox suite on a native amd64 runner and a native arm64 runner

Releases are cut by pushing a tag such as v1.2.0. The release workflow reruns all of CI, and only if every gate passes does it publish the multi-arch image to Docker Hub and GHCR (with SBOM and build provenance), check that both architectures start, update the Docker Hub description and create the GitHub release from the changelog. Dependabot keeps Python packages, the base image and Actions up to date.