GitLab Webhook/Polling: MR-Outcomes automatisch erfassen #27

New issue

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

David commented

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

Beschreibung

MR-Status-Änderungen (approved/changes_requested/closed/merged) aus GitLab automatisch erfassen — entweder über Webhooks oder periodisches Polling — und in den bestehenden Ticket-Feldern speichern.

Hintergrund

Die Felder mr_outcome, mr_reviewed_at und mr_comments_count existieren bereits im Ticket-Model, werden aber NIE befüllt. Ohne diese Daten ist kein Feedback-Loop möglich: keine Scoring-Kalibrierung, keine Erfolgsmetriken, kein Lernen aus Ergebnissen. Dies ist die technische Grundlage für Issue #19 (Feedback-Loop).

Akzeptanzkriterien

Für alle Tickets mit Status mr_created: MR-Status wird regelmäßig aus GitLab geholt
mr_outcome wird korrekt auf approved/changes_requested/closed/merged gesetzt
mr_reviewed_at wird mit dem Zeitpunkt der letzten Review-Aktion befüllt
mr_comments_count wird mit der Anzahl der Review-Kommentare befüllt
Optional: GitLab-Webhook-Endpoint POST /api/webhooks/gitlab für Echtzeit-Updates
Polling-Intervall konfigurierbar (Fallback wenn Webhooks nicht verfügbar)
Dashboard zeigt MR-Outcome auf der Ticket-Detailseite

Technische Hinweise

Erweitern: backend/services/gitlab_service.py — get_mr_status(mr_id, project), get_mr_comments(mr_id, project)
Neuer Scheduler-Job in backend/main.py — periodisches Polling aller offenen MRs
Optional: backend/api/webhooks.py — GitLab Webhook Receiver
Erweitern: backend/config.py — MR_POLL_INTERVAL_MINUTES, GITLAB_WEBHOOK_SECRET
Erweitern: frontend/src/pages/TicketDetail.tsx — MR-Outcome-Anzeige
Migration nötig: nein (Felder existieren bereits, werden nur befüllt)

Aufwand: M

## Beschreibung MR-Status-Änderungen (approved/changes_requested/closed/merged) aus GitLab automatisch erfassen — entweder über Webhooks oder periodisches Polling — und in den bestehenden Ticket-Feldern speichern. ## Hintergrund Die Felder `mr_outcome`, `mr_reviewed_at` und `mr_comments_count` existieren bereits im Ticket-Model, werden aber NIE befüllt. Ohne diese Daten ist kein Feedback-Loop möglich: keine Scoring-Kalibrierung, keine Erfolgsmetriken, kein Lernen aus Ergebnissen. Dies ist die technische Grundlage für Issue #19 (Feedback-Loop). ## Akzeptanzkriterien - [ ] Für alle Tickets mit Status `mr_created`: MR-Status wird regelmäßig aus GitLab geholt - [ ] `mr_outcome` wird korrekt auf approved/changes_requested/closed/merged gesetzt - [ ] `mr_reviewed_at` wird mit dem Zeitpunkt der letzten Review-Aktion befüllt - [ ] `mr_comments_count` wird mit der Anzahl der Review-Kommentare befüllt - [ ] Optional: GitLab-Webhook-Endpoint `POST /api/webhooks/gitlab` für Echtzeit-Updates - [ ] Polling-Intervall konfigurierbar (Fallback wenn Webhooks nicht verfügbar) - [ ] Dashboard zeigt MR-Outcome auf der Ticket-Detailseite ## Technische Hinweise - Erweitern: `backend/services/gitlab_service.py` — `get_mr_status(mr_id, project)`, `get_mr_comments(mr_id, project)` - Neuer Scheduler-Job in `backend/main.py` — periodisches Polling aller offenen MRs - Optional: `backend/api/webhooks.py` — GitLab Webhook Receiver - Erweitern: `backend/config.py` — `MR_POLL_INTERVAL_MINUTES`, `GITLAB_WEBHOOK_SECRET` - Erweitern: `frontend/src/pages/TicketDetail.tsx` — MR-Outcome-Anzeige - Migration nötig: nein (Felder existieren bereits, werden nur befüllt) ## Aufwand: M

David added the

labels

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

~~David referenced this issue 2026-03-30 20:27:56 +00:00~~

Post-Merge Verification & Automated Testing: Prüfen ob Fixes wirklich funktionieren #88

David referenced this issue

2026-03-30 20:30:26 +00:00