ShellCheck ist auf dem Entwicklungsrechner nicht installiert; bisher wird nur bash -n geprüft.
Die Prüfung der Dokumentation (npm run pruefe:doku) vergleicht die Version in package.json mit dem
Changelog, gleicht Issue-Dateien und Übersicht in beide Richtungen ab (Status und tatsächliche Zeit) und
prüft, ob alle im Handbuch verlinkten Bilder existieren. Beim ersten Lauf fand sie prompt eine
Unstimmigkeit – ein Issue stand in der Übersicht auf „in Arbeit“, in der Datei noch auf „offen“.
ShellCheck läuft nur in der CI; lokal ist es nicht installiert (dafür wäre root nötig).
Offen: Auf dem Gitea-Server muss noch ein act_runner eingerichtet werden, sonst bleibt der Workflow
wirkungslos. Ohne Runner erscheint er in Gitea gar nicht erst.
Quelle: docs/issues/019-ci-pipeline.md – dort wird dieses Issue gepflegt.
## Ziel
Automatische Prüfung jedes Commits, damit Fehler nicht erst beim Release auffallen.
## Aufgaben
- [x] Gitea Actions (oder Woodpecker) einrichten
- [x] Schritte: `npm ci`, `prisma generate`, Lint, Typecheck, Tests gegen eine PostgreSQL-Dienstinstanz, Build
- [x] ShellCheck für `agent/*.sh`
- [x] Prüfung, dass `docs/issues/README.md` und `DEVLOG.md` zur Version in `package.json` passen
- [x] Ergebnis als Kennzeichen im README
## Akzeptanzkriterien
- [x] Ein fehlschlagender Test verhindert den Merge nach `main`
- [x] Der Durchlauf dauert unter fünf Minuten
## Abhängigkeiten
#014
## Notizen / Entscheidungen
- ShellCheck ist auf dem Entwicklungsrechner nicht installiert; bisher wird nur `bash -n` geprüft.
- Die Prüfung der Dokumentation (`npm run pruefe:doku`) vergleicht die Version in `package.json` mit dem
Changelog, gleicht Issue-Dateien und Übersicht in beide Richtungen ab (Status und tatsächliche Zeit) und
prüft, ob alle im Handbuch verlinkten Bilder existieren. Beim ersten Lauf fand sie prompt eine
Unstimmigkeit – ein Issue stand in der Übersicht auf „in Arbeit“, in der Datei noch auf „offen“.
- ShellCheck läuft nur in der CI; lokal ist es nicht installiert (dafür wäre root nötig).
- **Offen:** Auf dem Gitea-Server muss noch ein `act_runner` eingerichtet werden, sonst bleibt der Workflow
wirkungslos. Ohne Runner erscheint er in Gitea gar nicht erst.
---
Quelle: `docs/issues/019-ci-pipeline.md` – dort wird dieses Issue gepflegt.
florian.wilde
added this to the v0.10.0 milestone 2026-09-17 19:43:05 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ziel
Automatische Prüfung jedes Commits, damit Fehler nicht erst beim Release auffallen.
Aufgaben
npm ci,prisma generate, Lint, Typecheck, Tests gegen eine PostgreSQL-Dienstinstanz, Buildagent/*.shdocs/issues/README.mdundDEVLOG.mdzur Version inpackage.jsonpassenAkzeptanzkriterien
mainAbhängigkeiten
#014
Notizen / Entscheidungen
bash -ngeprüft.npm run pruefe:doku) vergleicht die Version inpackage.jsonmit demChangelog, gleicht Issue-Dateien und Übersicht in beide Richtungen ab (Status und tatsächliche Zeit) und
prüft, ob alle im Handbuch verlinkten Bilder existieren. Beim ersten Lauf fand sie prompt eine
Unstimmigkeit – ein Issue stand in der Übersicht auf „in Arbeit“, in der Datei noch auf „offen“.
act_runnereingerichtet werden, sonst bleibt der Workflowwirkungslos. Ohne Runner erscheint er in Gitea gar nicht erst.
Quelle:
docs/issues/019-ci-pipeline.md– dort wird dieses Issue gepflegt.