Pipeline-Trigger einrichten

Ein Trigger startet eine Pipeline. Jeder ist ein Knoten auf der Zeichenfläche, den du aus dem Abschnitt Auslöser der Knotenbibliothek ablegst. Wählst du diesen Knoten, öffnet sich rechts sein Inspektor. Eine ständig sichtbare Trigger-Liste, einen Trigger-Tab oder einen eigenen Trigger-Bildschirm gibt es nicht.

Den Inspektor eines Triggers öffnen

Geh zu Einstellungen → Arbeitsbereich → Pipeline-Vorlagen.
Drücke den Stift in der Zeile der Vorlage, um den Editor zu öffnen.
Wähle einen Trigger-Knoten auf der Zeichenfläche. Rechts erscheint das Panel mit den Einstellungen dieses Triggers. Ist nichts ausgewählt, bleibt das Panel verborgen.

Einen Auslöser hinzufügen

Der Abschnitt Auslöser der Knotenbibliothek führt jede Startart als eigenen Knoten: manuell, Zeitplan, Webhook und eine Karte je Domain-Ereignis. Suche nach merged, ticket oder dem Typnamen (PrMerged) und ziehe die Karte auf die Zeichenfläche. Eine neue Vorlage zeigt am Eingang außerdem die leere Kachel Auslöser hinzufügen — wähle aus derselben durchsuchbaren Liste.

Der Trigger wird sofort eingefügt. Neue automatische Trigger starten deaktiviert, damit das Ablegen keinen Lauf auslöst, bevor du ihn konfiguriert hast. Schalte ihn mit Aktiviert im Inspektor ein, oder lösche ihn über das Papierkorb-Symbol.

Manuelle Läufe zulassen

Lege Manueller Lauf ab (oder wähle ihn über die leere Kachel) und schalte im Inspektor Aktiviert ein. Dadurch erscheint die Vorlage unter „Pipeline ausführen“. Der Schalter schreibt eine gewöhnliche Trigger-Zeile mit dem Ereignistyp manual. Sie wird sofort übernommen; es gibt nichts zu speichern.

Derselbe Schalter steckt hinter Manuelle Ausführung in der Kopfzeile des Editors, neben den deklarierten Eingaben der Vorlage.

Bei einem Ereignis

Diese Ereignisse starten einen Lauf:

Bezeichnung in der Auswahl	Ereignis
Externe PR geöffnet	`ExternalPrDetected`
PR veröffentlicht	`PullRequestPublished`
PR-Status geändert	`PullRequestStatusChanged`
PR zusammengeführt	`PrMerged`
Nachricht empfangen	`MessageReceived`
Ticket erstellt	`TicketCreated`
Ticket-Status geändert	`TicketStatusChanged`
Ticket zugewiesen	`TicketAssigned`
Aufgabe abgeschlossen	`TicketCompleted`
Aufgabe fehlgeschlagen	`TicketFailed`
Aufgabe abgebrochen	`TicketCancelled`
Budgetschwelle überschritten	`BudgetThresholdCrossed`
Repository hinzugefügt	`RepoAdded`
Meeting-Aufnahme beendet	`MeetingRecordingStopped`
Fähigkeit aktualisiert	`SkillUpdated`
Bereich gelöscht	`SpaceDeleted`

SpaceDeleted ist das Ereignis, auf das die mitgelieferte Pipeline zur Worktree-Bereinigung hört: es trägt die ID des gelöschten Bereichs, der Lauf räumt also genau die Worktrees dieses Bereichs auf, statt den ganzen Arbeitsbereich zu durchsuchen.

Welche Payload-Schlüssel jedes Ereignis trägt, steht in der Referenz der Domain-Ereignisse.

Einen Ereignis-Trigger filtern

Wähle den Knoten PR-Status geändert. Die Status-Chips im Inspektor sind der einzige Filter, den die Oberfläche anlegen kann. Tippe eines von merged, closed, approved, opened, reopened an; der Trigger feuert dann nur, wenn status des Ereignisses zu einem davon passt. Lässt du jeden Chip ungewählt, gilt kein Filter.

Ein freies JSON-Filterfeld gibt es nicht. Ein Filterschlüssel, den die Payload des Ereignisses nicht trägt, passt nie. Leg also keinen von Hand gegen einen Schlüssel an, den du in der Referenz der Domain-Ereignisse nicht bestätigt hast.

Nach Zeitplan

Wähle den Knoten Zeitplan, um einzustellen, wann er auslöst. Die Felder im Inspektor bleiben erhalten, sobald du sie verlässt:

Feld	Beschreibung
Zeitplan (cron oder every:Sekunden)	Ein Cron-Ausdruck mit fünf Feldern wie `0 9 * * 1`, oder ein Intervall wie `every:86400`. Eine Zahl ohne Präfix wird zu `every:<n>`.
Zeitzone (optional)	Eine IANA-Zone wie `Europe/Paris`. Vorgabe ist UTC.
Bei verpassten Läufen	Was mit Auslösungen geschehen soll, die verpasst wurden, während der Server aus war: Einmal ausführen fasst jeden verpassten Zeitpunkt beim Neustart zu einer Auslösung zusammen (die Vorgabe), Überspringen setzt beim nächsten zukünftigen Zeitpunkt fort.

Die Zusammenfassungszeile der Kachel auf der Zeichenfläche schreibt das Intervall nur bei der Form every:<seconds> aus; ein Cron-Ausdruck erscheint nur als „Zeitplan“.

Per Webhook

Legst du Webhook ab, wird ein zufälliges Token erzeugt. Wähle den Knoten, um den Pfad POST /webhooks/<token> aus dem Inspektor zu kopieren.

Das Token ist zugleich das HMAC-Geheimnis: die Anfrage muss X-Hub-Signature-256: sha256=<hex> tragen, wobei das Hex HMAC-SHA256(body, token) ist. Eine Zustellung, die die Prüfung nicht besteht, wird abgelehnt, protokolliert und lässt sich nicht wiederholen. Duplikate werden anhand ihres Deduplizierungsschlüssels ignoriert.

Jeder Start ist ein eigener Knoten im Graphen. Eine Leitung von Zeitplan hängt nur den Zeitplan an; Manueller Lauf kann einen anderen Weg nehmen (zum Beispiel über einen Knoten Condition / switch (router)), bevor er in dieselbe Arbeit mündet. Ein Lauf betritt den Start, der zu seinem Ereignistyp passt, und überspringt Teilgraphen der anderen Starts.

Wie ein Trigger einen Lauf erreicht

Ein aktivierter Trigger, bei dem Ereignistyp und Filter passen, startet einen Lauf mit der Payload des Ereignisses als Trigger-Payload des Laufs — dagegen löst {{key}} im Prompt oder Skript eines Schritts auf. Ereignisse mit einem natürlichen Schlüssel werden dedupliziert, sodass dasselbe Ereignis bei zweimaligem Auslösen nicht zwei Läufe startet.

Eine deaktivierte Vorlage wird abgelehnt, auch wenn ihr Trigger passt. Acht der dreizehn mitgelieferten Vorlagen werden deaktiviert ausgeliefert, ihre angelegten Trigger laufen also ins Leere, bis du die Vorlage einschaltest.

Nützliche Muster

Nur den manuellen Pfad absichern — verbinde Manueller Lauf über einen Knoten Condition / switch (router) und Zeitplan direkt mit der Arbeit. Jeder Start hat seine eigenen Leitungen.
Jeden neuen PR prüfen — Ereignis PR veröffentlicht an der Vorlage pr_review.
Nach einem Merge aufräumen — Ereignis PR-Status geändert, gefiltert auf merged / closed / approved. Die mitgelieferte Vorlage pr_merged_cleanup hört bereits so, dazu Aufgabe abgeschlossen und Aufgabe abgebrochen, SpaceDeleted und ein täglicher Zeitplan, der bei jedem erneuten Seeding zwingend aktiviert wird, weil es die Bereinigung ist.
Nächtlicher Durchlauf — Zeitplan 0 2 * * * mit einer Zeitzone, an einer Vorlage, deren erster Knoten Bash script ist.
Auf ein externes System reagieren — ein Webhook-Trigger, wobei das aufrufende System den Request-Body wie oben signiert.