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 und GitHub erscheint jeder Lauf -- du brauchst keinen offenen Merge- bzw. Pull-Request. Bei Bitbucket erscheinen Läufe weiterhin neben einem offenen Pull Request. Falls die Seite leer bleibt, siehe Voraussetzungen.

Läuft gerade

Ganz oben auf der Seite -- über der gefilterten Liste und unabhängig vom aktiven Filter -- sitzt das Panel Läuft gerade. Es zeigt alles, was aktuell in Arbeit oder eingereiht ist.

Das ist wichtig, weil der Standard-Filter Aufmerksamkeit nötig ist und ein gesunder laufender Job dort per Definition nicht auftaucht. Ohne das Panel wäre ein Lauf, den du gerade gestartet hast, erst nach einem Filterwechsel sichtbar.

• Angezeigt werden die ersten fünf in Arbeit befindlichen Läufe. Gibt es mehr, steht darunter ein Hinweis, wie viele weitere gerade laufen -- mit einem Klick auf Alle laufenden.
• Die Dauer zählt live hoch, statt leer zu bleiben, bis der Lauf fertig ist.
• Läufe im Panel werden aus der Liste darunter entfernt -- keine Karte erscheint doppelt.
• Auch ein gerade erst angestoßener Lauf zählt schon als laufend, solange er noch in der Warteschlange hängt.

Die Liste darunter sortiert nach Dringlichkeit: Aufmerksamkeit nötig → aktiv → zuletzt beendet. Ein noch laufender Job steht also über einem, der eine Sekunde vorher grün wurde.

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: Workflow-Läufe auch ohne Pull Request

GitHub-Workflow-Läufe werden -- wie GitLab-Pipelines -- eigenständig erfasst. Damit erscheinen auch Läufe auf dem Default-Branch, auf Tags, aus Schedules und manuell gestartete Workflows in der Ansicht, ganz ohne offenen Pull Request. Jeder Lauf zeigt den Branch bzw. Tag und den Auslöser; der Workflow selbst steht als einzelner Schritt in der Zeile. Die Detailtiefe pro Job (Check-Runs) liegt weiterhin an der Pull-Request-Ansicht.

Kein Nachtrag für die Vergangenheit: Ältere Workflow-Läufe ohne Pull Request erscheinen nicht rückwirkend. Ein Repository füllt sich, sobald der nächste Workflow startet.

Bitbucket: aus Pull-Request-Steps gruppiert

Bei 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. Dasselbe gilt für GitHub-Check-Runs und Commit-Status, die zusätzlich zu den Workflow-Läufen an einem PR hängen.

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. Der aufgeklappte Graph nutzt die volle Kartenbreite; passt er nicht ins Bild, scrollt er horizontal in seinem eigenen Bereich (auf dem Handy zeigt eine weiche Kante, auf welcher Seite noch etwas kommt)
• 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 jeder Workflow-Lauf (Branch, Tag, Schedule oder manuell gestartet) -- kein offener Pull Request nötig. Dafür muss das Event Workflow run abonniert sein (siehe unten). Historische Läufe erscheinen nicht rückwirkend.
   • Bei Bitbucket ein offener oder Draft-Pull-Request mit mindestens einem CI-Step.

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.