Pipelines

Die Pipelines-Seite gibt dir eine zentrale Übersicht über die CI/CD-Aktivität aller verbundenen Git-Provider. Statt GitHub Actions, GitLab Pipelines und Bitbucket Builds einzeln zu öffnen, siehst du alle Läufe in einer Liste -- so sortiert, dass die Läufe, die deine Aufmerksamkeit brauchen, ganz oben stehen.

Sie ist das Gegenstück zur Pull-Requests-Ansicht: Pull Requests fokussieren auf die Änderung, Pipelines auf die CI-Läufe dazu.

Feature aktivieren

Die Pipelines-Ansicht hat ein eigenes Feature-Flag, unabhängig von der Pull-Requests-Ansicht:

1. Gehe zu Einstellungen → Features
2. Aktiviere PIPELINES_VIEW
3. Der neue Eintrag Pipelines erscheint in der Seitennavigation

Damit Läufe erscheinen, brauchst du mindestens eine verbundene Git-Integration (GitHub, GitLab oder Bitbucket), ein mit einem Board verknüpftes Repository und einen offenen Pull-/Merge-Request mit CI. Falls die Seite leer bleibt, siehe Voraussetzungen.

Wie Pipelines funktionieren

Spedy speichert kein eigenes Pipeline-Modell. Pipeline-„Läufe" werden zur Laufzeit aus den Pull-Request-Daten abgeleitet -- derselbe Webhook-Strom, der die Pull-Requests-Ansicht speist, speist also auch die Pipelines.

Der Datenfluss:

1. Webhook rein. GitHub, GitLab oder Bitbucket sendet ein CI-Event. Spedy verifiziert die Signatur und löst die Installation zur passenden Integration auf.
2. Normalisieren. Das Event wird in einen provider-agnostischen Step übersetzt und als PullRequestStep-Zeile am zugehörigen Pull-/Merge-Request gespeichert.
3. Live-Update. Ein pull-request:updated-Event geht an den Echtzeit-Raum des Boards, sodass die Seite sich ohne Reload aktualisiert.
4. Zu Läufen gruppieren. Beim Öffnen der Seite liest Spedy offene und Draft-PRs samt ihrer Steps und gruppiert die Steps zu Läufen. Ein Re-Run erzeugt einen neuen Lauf, weil der Provider eine frische Suite-/Pipeline-ID vergibt.

Da Läufe virtuell sind, gibt es nichts zu konfigurieren oder aufzuräumen -- die Ansicht spiegelt immer den aktuellen Stand deiner PRs.

Lauf-Status und Step-Status

Jeder Lauf fasst den Status seiner Steps zusammen:

Einzelne Steps sind typisiert (Review, Check, Build, Test, Deploy, Release, Artifact, Other) und tragen ihren eigenen Status (ausstehend, laufend, erfolgreich, fehlgeschlagen, übersprungen, manuell, abgebrochen, unbekannt).

Status-Buckets

Jeder Lauf wird einem von fünf Buckets zugeordnet, wählbar in der Seitenleiste:

• Aufmerksamkeit nötig (Standard) -- Läufe, die fehlgeschlagen sind, auf ein manuelles Gate warten oder festhängen (länger als 30 Minuten laufend oder ausstehend)
• Laufend -- aktuell in Arbeit
• Fehlgeschlagen -- fehlgeschlagen oder teilweise fehlgeschlagen
• Erfolgreich -- alle Steps bestanden
• Alle -- jeder Lauf

Der Standard-Bucket ist Aufmerksamkeit nötig. Wenn alle deine Pipelines grün sind, ist die Standardansicht bewusst leer -- wechsle auf Alle, um alles zu sehen. Der Leerzustand bietet genau dafür eine Ein-Klick-Abkürzung.

Was du tun kannst (schreibgeschützte Ansicht)

Die Pipelines-Seite ist schreibgeschützt. Sie zeigt CI-Status an; sie steuert deine CI nicht. Du kannst:

• Läufe als Liste ansehen -- mit Status-Dot, Branch, Author, Dauer und Step-Dots -- oder als Stage-Graph
• nach Status-Bucket, nach Provider (GitHub / GitLab / Bitbucket) und nach Board filtern
• Live-Updates per WebSocket erhalten, während die CI läuft

Was du hier nicht kannst (bewusst so):

• Pipeline-Steps auslösen, neu starten oder abbrechen
• CI konfigurieren oder Workflows bearbeiten
• Repositories oder Board↔Repo-Zuordnungen verwalten (das machst du unter Board-Einstellungen → Integrationen)

Voraussetzungen (warum die Seite leer ist)

Ein Lauf erscheint nur, wenn alle folgenden Bedingungen erfüllt sind:

1. PIPELINES_VIEW ist für deine Organisation aktiviert
2. Eine aktive Git-Integration existiert (GitHub, GitLab oder Bitbucket)
3. Das Repository ist mit einem Board verknüpft, auf das du Zugriff hast
4. Es gibt einen offenen oder Draft-Pull-/Merge-Request auf diesem Repository
5. Der PR hat mindestens einen CI-Step -- der bei GitHub per Webhook eintrifft (siehe unten)

Daten sind immer auf die für dich zugänglichen Boards beschränkt, und die Seite steht nur Admins und Team-Mitgliedern offen (nicht Kund:innen).

CI-Events pro Provider einrichten

GitHub App: benötigte Event-Abonnements

GitHub-CI-Steps werden per Webhook geliefert. Die Spedy GitHub App muss die richtigen Events abonnieren -- sonst bleibt die Pipelines-Seite leer, obwohl alles andere korrekt eingerichtet ist.

In den GitHub-App-Einstellungen unter Permissions & events → Subscribe to events aktivieren:

Reihenfolge beachten: Check run und Check suite erscheinen in der Events-Liste erst, wenn die App die Repository-Permission Checks: Read hat. Erst die Permission setzen, dann werden die Events auswählbar.

Die App-Lifecycle-Events (Installation, Installation repositories, Meta/ping) werden automatisch verarbeitet. Events wie Workflow job, Issues, Star oder Release werden für Pipelines nicht benötigt.

• Webhook-URL: POST https://<api-host>/api/v1/webhooks/github/app
• Signatur: HMAC-SHA256 im Header x-hub-signature-256, signiert mit GH_APP_WEBHOOK_SECRET

GitLab und Bitbucket

Für GitLab legt Spedy den Repository-Webhook automatisch an, sobald du ein Repository mit einem Board verknüpfst (Push-, Merge-Request- und Pipeline-Events). Du brauchst mindestens die Maintainer-Rolle im Projekt. Siehe Integrationen → GitLab.

Für Bitbucket wird der Webhook ebenfalls beim Verknüpfen des Repositories erstellt, mit den Token-Scopes, die unter Integrationen → Bitbucket aufgeführt sind.

Backfill und manueller Sync

Webhooks liefern den CI-Status live, aber ein frisch verbundenes Repository -- oder eines, dessen Webhook erst nach Anlegen eines PRs hinzugefügt wurde -- hat keine Historie. Ein täglicher Hintergrund-Sync um 2 Uhr importiert offene PRs (und in den letzten 90 Tagen gemergte PRs) erneut und zieht aktuelle CI-Läufe nach, damit die Ansicht vollständig ist.

Du kannst den Sync auch manuell auslösen über POST /pull-requests/sync (nur Admin).

GitHub-Hinweis: CI-Steps für GitHub werden während dieses Syncs ebenfalls aus den Check-Runs befüllt -- ein Repo, das erst nach Anlegen seiner PRs verbunden wurde, füllt die Pipelines-Ansicht also auch, nicht nur über Live-Webhooks.

Unterstützte Provider

Alle drei werden in dasselbe Lauf-und-Step-Modell normalisiert, sodass die Erfahrung unabhängig vom Provider konsistent ist.