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) und ein mit einem Board verknüpftes Repository. Bei GitLab erscheint jede Pipeline -- du brauchst keinen offenen Merge Request. Bei GitHub und Bitbucket erscheinen Läufe weiterhin neben einem offenen Pull Request. Falls die Seite leer bleibt, siehe Voraussetzungen.

Wie Pipelines funktionieren

GitLab: jede Pipeline, nicht nur die mit Merge Request

GitLab-Pipelines sind jetzt eigenständig: Spedy erfasst jede Pipeline, die es empfängt -- egal, ob ein offener Merge Request dazu existiert. So erscheinen Pipelines auf dem Default-Branch, auf einem Branch ohne offenen MR, auf Tags oder aus Schedules allesamt in der Ansicht. Bisher zeigte sich nur, was an einem offenen Merge Request hing, wodurch viele Repositories leer wirkten.

Jeder GitLab-Lauf zeigt den Branch bzw. Tag, auf dem er lief, und den Auslöser (Push, Tag, Schedule usw.). Ein PR-Chip erscheint nur dann, wenn tatsächlich ein Merge Request mit dem Lauf verknüpft ist.

GitHub und Bitbucket: aus Pull-Request-Steps gruppiert

Bei GitHub und Bitbucket werden „Läufe" aus den Pull-Request-Daten abgeleitet -- derselbe Webhook-Strom, der die Pull-Requests-Ansicht speist, speist also auch die Pipelines. Diese Läufe erscheinen neben ihrem offenen oder Draft-Pull-Request.

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. GitLab-Pipelines werden in eigene Pipeline-Datensätze geschrieben; GitHub- und Bitbucket-Steps hängen an ihrem Pull-/Merge-Request.
3. Live-Update. Ein Echtzeit-Event geht an den Raum des Boards, sodass die Seite sich ohne Reload aktualisiert.
4. Zu Läufen gruppieren. Beim Öffnen der Seite liest Spedy die GitLab-Pipelines sowie die GitHub-/Bitbucket-Pull-Request-Steps und gruppiert sie zu Läufen. Ein Re-Run erzeugt einen neuen Lauf, weil der Provider eine frische Suite-/Pipeline-ID vergibt.

Es gibt nichts zu konfigurieren oder aufzuräumen -- die Ansicht spiegelt immer den aktuellen Stand deiner Pipelines und 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 CI-Aktivität zum Anzeigen:
   • Bei GitLab jede Pipeline (auf Branch, Tag oder aus einem Schedule) -- kein offener Merge Request nötig.
   • Bei GitHub und Bitbucket ein offener oder Draft-Pull-Request mit mindestens einem 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.