CI/CD

Übersicht

CI/CD läuft über Drone CI (selbst gehostet auf ci.mrrm.de), Quellcode in Forgejo (git.mrrm.de). Konfiguration: .drone.yml im Root.

Pipelines

Pipeline	Trigger	Zweck
ci	Push + PR auf alle Branches	Typecheck, Lint, Test, Build
ci-ocr	Push/PR wenn apps/ocr/** geändert	Python-Tests
publish-api	Push auf main (nach ci)	Docker-Image API bauen + pushen
publish-web	Push auf main (nach ci)	Docker-Image Web bauen + pushen
publish-ocr	Push auf main (nach ci)	Docker-Image OCR bauen + pushen
publish-android-builder	Push auf main wenn infra/android-builder/Dockerfile geändert	Android-Builder-Image
publish-fdroid-server	Push auf main wenn infra/fdroid/Dockerfile geändert	F-Droid-Server-Image
publish-apk	Push auf main (nach ci)	Android APK bauen + zu F-Droid hochladen
deploy	Push auf main (nach publish-api/web/ocr)	Produktion deployen
deploy-dev	Push auf main	Dev-Umgebung deployen
e2e-mobile	Cron nightly-e2e + manueller custom-Build	Maestro-Flows im Android-Emulator

ci-Pipeline im Detail

install → typecheck (--concurrency=1)
        → lint (api + shared-types)
        → test (api + mobile)
        → test-integration (api gegen Postgres-Service)
        → build-api
        → build-web (NODE_OPTIONS=--max-old-space-size=2048)
        → e2e-web (Playwright; Web + API + Paperless-Mock)

Der test-Step führt Vitest-Tests in apps/api und apps/mobile aus. Mobile umfasst Pure-Logic-Tests (src/**/*.spec.ts) und Component-Tests (__tests__/**/*.test.tsx, via react-native-web alias).

Wichtig: turbo run typecheck --concurrency=1 — parallele tsc-Prozesse erschöpfen den RAM des Runners (Exit 137).

Mobile E2E (Maestro)

YAML-Flows in apps/mobile/.maestro/, ausgeführt mit Maestro CLI (Apache 2.0). Lokal: manuelle Ausführung gegen ein per ADB verbundenes Gerät; in CI: nightly + on-demand via e2e-mobile-Pipeline (siehe unten).

Vorhandene Flows:

• login.yaml — Anmelden → Lists-Overview sichtbar
• lists-smoke.yaml — Anmelden → Liste anlegen → Item adden → Item sichtbar

# Dev-APK installiert (de.mrrm.mrrmlab.dev)
adb devices                 # ein Gerät online?
pnpm --filter @mrrmlab/mobile run test:maestro
# oder: cd apps/mobile && maestro test .maestro/login.yaml

Maestro CLI installieren: curl -Ls "https://get.maestro.mobile.dev" | bash (oder brew tap mobile-dev-inc/tap && brew install maestro).

e2e-mobile-Pipeline (Emulator-im-Drone)

install → build-debug-apk → maestro-test (mit emulator-Service)

• Service emulator: budtmo/docker-android:emulator_11.0, privileged: true, /dev/kvm als Volume — startet Android 11 Emulator, exposed ADB auf Port 5555/5037
• Build: gradlew assembleDebug mit reactNativeArchitectures=x86_64 (Emulator-CPU)
• Test: Maestro CLI installiert ad-hoc per curl, ADB_SERVER_SOCKET=tcp:emulator:5037, läuft alle .maestro/-Flows

Voraussetzungen (einmaliges Setup):

1. Repo in Drone unter Settings als Trusted markieren — sonst sind privileged: true + host-volumes verboten
2. dev-neu Host muss /dev/kvm verfügbar haben (x86_64 mit aktivierter CPU-Virtualization)
3. Cron nightly-e2e in Drone UI anlegen (Settings → Crons, z.B. 0 3 * * *)

Triggern auf Bedarf: Drone UI → "New Build" → event custom — startet die Pipeline manuell.

Alternativen (nicht implementiert)

Option	Setup	Laufzeit	Trade-off
Emulator-im-Drone (aktiv)	dev-neu /dev/kvm + Trusted-Repo	~10-15min/Run	nightly, nicht jeder PR
ADB-on-RPi5 (physisches Gerät)	RPi5 mit USB-Phone, ADB-over-SSH	~30s/Test	schnell, Phone muss verfügbar bleiben
Maestro Cloud	Account/Tokens	abhängig	kostenpflichtig je nach Volumen

Drone Secrets

Werden in Drone CI unter Repository → Settings → Secrets gepflegt:

Secret	Verwendung
registry-username	Forgejo Container Registry
registry-password	Forgejo Container Registry
android-keystore-base64	APK-Signing (base64-kodierte .jks)
android-key-alias	APK-Signing
android-key-password	APK-Signing
android-store-password	APK-Signing
deploy-ssh-host	Produktions-Server SSH
deploy-ssh-user	Produktions-Server SSH
deploy-ssh-key	Produktions-Server SSH
deploy-ssh-port	Produktions-Server SSH

Container Registry

Images werden in der Forgejo-eigenen Registry gespeichert: git.mrrm.de/admin-mrrm/mrrmlabapp/<service>:latest

Kein SHA-Tagging (spart Speicher — nur latest wird behalten).

Disk-Space-Hinweise

Der CI-Server hat 78 GB. Alte Registry-Images können sich aufhäufen. Regelmäßige Bereinigung via Forgejo-API:

TOKEN=$(cat ~/.gitea-token)
curl -X DELETE -H "Authorization: token $TOKEN" \
  "https://git.mrrm.de/api/v1/packages/admin-mrrm/container/<name>/<version>"