MR-Erfolgs-Tracking: GitLab-Polling für MR-Outcomes implementieren #16

New issue

David · 2026-03-30T19:24:46Z

David commented

2026-03-30 19:24:46 +00:00

Beschreibung

Die Felder mr_reviewed_at, mr_outcome und mr_comments_count sind im Ticket-Model definiert, werden aber nie befüllt. Es fehlt ein Mechanismus (GitLab-Polling oder Webhook), der den Status erstellter MRs zurück in die DB schreibt.

Hintergrund

Ohne MR-Tracking ist unklar:

Wie viele automatisch erstellte MRs wurden approved vs. abgelehnt?
Wie ist die Trefferquote des Systems?
Welche Ticket-Typen führen zu schlechten MRs?

Die Stats-Berechnung in /api/stats existiert bereits (success_rate, mrs_approved), aber die Daten fehlen. Die PROJEKT-SPEC.md beschreibt dies in Phase 4.1.

Akzeptanzkriterien

Scheduled Job pollt GitLab alle 10 Minuten für MR-Status-Updates
mr_outcome wird korrekt gesetzt: approved / changes_requested / closed
mr_reviewed_at wird auf den Zeitpunkt des letzten Review-Events gesetzt
mr_comments_count zählt die Review-Kommentare auf dem MR
TicketResponse Pydantic-Model enthält die MR-Tracking-Felder
Dashboard zeigt MR-Status pro Ticket an (approved/pending/changes requested)
/api/stats zeigt korrekte Trefferquote basierend auf echten Daten
Tests mit gemockter GitLab-API

Technische Hinweise

Betroffene Dateien:
- Ändern: backend/services/gitlab_service.py (neue Methode sync_mr_outcomes())
- Ändern: backend/main.py (neuer Scheduled Job poll_mr_outcomes_job)
- Ändern: backend/api/tickets.py (TicketResponse erweitern)
- Ändern: frontend/src/pages/TicketDetail.tsx (MR-Status anzeigen)
- Ändern: frontend/src/components/TicketCard.tsx (MR-Badge)
Ansatz: project.mergerequests.get(mr_iid) für jeden offenen MR, Status + Notes abfragen
Alternative: GitLab Webhook statt Polling (komplexer, aber effizienter)
Migration nötig: nein (Felder existieren bereits)

Aufwand: M

## Beschreibung Die Felder `mr_reviewed_at`, `mr_outcome` und `mr_comments_count` sind im Ticket-Model definiert, werden aber nie befüllt. Es fehlt ein Mechanismus (GitLab-Polling oder Webhook), der den Status erstellter MRs zurück in die DB schreibt. ## Hintergrund Ohne MR-Tracking ist unklar: - Wie viele automatisch erstellte MRs wurden approved vs. abgelehnt? - Wie ist die Trefferquote des Systems? - Welche Ticket-Typen führen zu schlechten MRs? Die Stats-Berechnung in `/api/stats` existiert bereits (`success_rate`, `mrs_approved`), aber die Daten fehlen. Die PROJEKT-SPEC.md beschreibt dies in Phase 4.1. ## Akzeptanzkriterien - [ ] Scheduled Job pollt GitLab alle 10 Minuten für MR-Status-Updates - [ ] `mr_outcome` wird korrekt gesetzt: `approved` / `changes_requested` / `closed` - [ ] `mr_reviewed_at` wird auf den Zeitpunkt des letzten Review-Events gesetzt - [ ] `mr_comments_count` zählt die Review-Kommentare auf dem MR - [ ] `TicketResponse` Pydantic-Model enthält die MR-Tracking-Felder - [ ] Dashboard zeigt MR-Status pro Ticket an (approved/pending/changes requested) - [ ] `/api/stats` zeigt korrekte Trefferquote basierend auf echten Daten - [ ] Tests mit gemockter GitLab-API ## Technische Hinweise - Betroffene Dateien: - Ändern: `backend/services/gitlab_service.py` (neue Methode `sync_mr_outcomes()`) - Ändern: `backend/main.py` (neuer Scheduled Job `poll_mr_outcomes_job`) - Ändern: `backend/api/tickets.py` (TicketResponse erweitern) - Ändern: `frontend/src/pages/TicketDetail.tsx` (MR-Status anzeigen) - Ändern: `frontend/src/components/TicketCard.tsx` (MR-Badge) - Ansatz: `project.mergerequests.get(mr_iid)` für jeden offenen MR, Status + Notes abfragen - Alternative: GitLab Webhook statt Polling (komplexer, aber effizienter) - Migration nötig: nein (Felder existieren bereits) ## Aufwand: M

David added the

labels

2026-03-30 19:24:46 +00:00

David referenced this issue

2026-03-30 20:19:01 +00:00