Deine Workflows verwalten

Einen Workflow zu bauen und mit zwanzig davon zu leben sind zwei verschiedene Aufgaben. Das Tutorial Deinen ersten Workflow erstellen behandelt Canvas, Node-Palette und Trigger-Lane; diese Seite behandelt die Liste, in der sie alle landen – wie du den gesuchten Workflow findest, an seinem Zustand abliest, ob er gesund ist, ihn von Hand startest, ihn per YAML zwischen Projekten bewegst und ihn gefahrlos stilllegst.

Wo die Liste liegt

Die Workflow-Liste ist der erste Tab des Build-Hubs, und die Landeseite des Hubs ist die Liste selbst. Die kanonische URL lautet /build – nicht /build/workflows, dort liegen nur die tieferen Seiten (der Builder, die Vorlagen-Galerie, die Ansicht für ungeleitete E-Mails). Die Nachbar-Tabs Skripte, Apps und Zeitpläne liegen ein Segment tiefer.

Ein altes /workflows-Lesezeichen funktioniert weiterhin: es leitet auf /build um, und /workflows/<id> auf /build/workflows/<id>. Die Umleitung ist eine Höflichkeit gegenüber alten Links – teile also die Hub-URL statt der Umleitung, siehe Navigation und Hubs.

Die Liste zeigt genau ein Projekt

Alles auf dieser Seite – die Kennzahlen, die Zeilen, die Facetten – ist auf das Projekt beschränkt, das du in der Aktionsleiste neben den Tabs auswählst (beschriftet Projekt). Ein Workspace mit mehreren Projekten zeigt immer nur eines; wechsle es, um die Workflows eines anderen Projekts zu sehen. Gibt es noch kein Projekt, sagt die Seite das, statt eine leere Tabelle zu zeigen.

Die Liste lesen

Über der Tabelle steht eine Leiste aus fünf Kennzahlen. Alle fünf beziehen sich auf das gewählte Projekt, die drei zeitbezogenen auf die letzten 24 Stunden:

• Aktive Läufe – Läufe der Workflows dieses Projekts, die noch laufen; die Unterzeile nennt, über wie viele Workflows sie sich verteilen.
• Workflows – wie viele es gibt, und über wie viele Projekte insgesamt.
• Erfolg 24h – abgeschlossene Läufe geteilt durch abgeschlossene plus fehlgeschlagene. Die Unterzeile nennt die genaue Stichprobe, sodass ein schmeichelhafter Prozentwert über drei Läufe als solcher erkennbar bleibt.
• Fehlläufe 24h – die Zahl der Fehlschläge und wie viele Workflows betroffen sind. Die Karte färbt sich rot, sobald der Wert über null liegt.
• Dauer – die mediane Laufzeit (nicht der Mittelwert, damit ein einzelner Ausreißer sie nicht verschiebt), über die in der Unterzeile genannte Stichprobe.

Jede Zeile darunter beschreibt einen Workflow:

Spalte	Was sie dir sagt
Workflow	Der Name, davor eine farbige Kachel mit dem Anfangsbuchstaben der Trigger-Art. Die Unterzeile lautet Projekt · Detail, wobei das Detail die konkrete Einstellung des Triggers ist – ein Git-Branch, ein Telegram-Kommando, der +slug eines E-Mail-Alias, ein Betreff-Filter. Trigger ohne solches Detail (Manuell, Webhook, Zeitplan, Discord, IMAP) zeigen nur das Projekt.
Status	Das Ergebnis des letzten Laufs, als Läuft, Fertig, Fehler, Bereit oder Abgebrochen. Ein nie gelaufener Workflow steht auf Bereit.
Knoten	Wie viele Knoten der Graph hat.
Läufe 24h	Wie viele Läufe in den letzten 24 Stunden gestartet sind, in jedem Zustand – 0 eingeschlossen.
Erfolg	Abgeschlossene geteilt durch abgeschlossene plus fehlgeschlagene Läufe, über dieselben 24 Stunden, als Prozentwert. Ein Gedankenstrich bedeutet, dass im Fenster kein Lauf fertig geworden ist – entweder lief nichts, oder alles Gelaufene ist noch unterwegs.
Auslöser	Die Art des primären Auslösers des Workflows.
Letzter Lauf	Wie lange der jüngste Lauf her ist, oder Nie gelaufen.

Auf dem Telefon werden Läufe 24h und Erfolg ausgeblendet; die Karte behält Name, Statuswort und Knotenzahl.

Eine niedrige Erfolgsquote lesen

Erfolg ist ein Verhältnis über ein bewusst schmales Fenster – lies es also zusammen mit seinen Nachbarn, bevor du daraus etwas schließt:

• Ein niedriger Prozentwert neben einem hohen Läufe 24h ist das echte Signal: der Workflow feuert oft und scheitert oft. Öffne ihn und sieh nach, wo die Läufe stehenbleiben.
• Ein niedriger Prozentwert neben Läufe 24h von 1 oder 2 ist Arithmetik, keine Diagnose. Ein Fehlschlag von zwei Läufen sind 50 %.
• Ein Gedankenstrich bei Läufe 24h über null heißt, dass die Läufe nicht fertig geworden sind – ein Workflow, der an einem Human-Node auf eine Freigabe wartet, steht hier beliebig lange, weil ihn noch niemand entschieden hat.
• Abgebrochene Läufe zählen in keiner Hälfte des Verhältnisses. Sie treiben Läufe 24h nach oben, ohne Erfolg überhaupt zu bewegen.

Den gesuchten Workflow finden

Die Werkzeugleiste über der Tabelle filtert und sortiert auf dem Server und durchsucht damit das ganze Projekt, nicht nur die Seite, die du gerade siehst.

1. Wähle über Filter eine Lebenszyklus-Sicht. Die vier Kategorien sind präzise:

   • Alle – kein Filter.
   • Aktiv – der jüngste Lauf ist noch unterwegs. Ein Lauf, der an einer Freigabe wartet, zählt als aktiv – das ist meist genau richtig, denn er wartet auf einen Menschen, er hängt nicht fest.
   • Mit Fehlern – der jüngste Lauf ist fehlgeschlagen. Abgebrochene Läufe erscheinen hier nicht.
   • Geplant – der primäre Auslöser des Workflows ist ein Zeitplan. Das ist eine Eigenschaft der Verdrahtung, nicht eines Laufs.

2. Grenze weiter ein über Auslöser (Manuell, Zeitplan, Git, Webhook, Telegram, Discord, IMAP, E-Mail, App-Lauf) und Status (Läuft, Fertig, Fehler, Bereit, Abgebrochen). Beide stehen anfangs auf Alle und kombinieren sich mit der Sicht darüber.

3. Tippe ins Suchfeld, um Workflows nach Namen zu finden.

4. Klicke auf eine Spaltenüberschrift, um zu sortieren. Workflow, Status, Knoten, Läufe 24h, Erfolg, Auslöser und Letzter Lauf sind alle sortierbar – nach Letzter Lauf zu sortieren ist der schnellste Weg, einen Workflow aufzuspüren, der still aufgehört hat zu feuern.

5. Über Spalten blendest du aus, was du auf einem schmalen Bildschirm nicht brauchst.

Welcher Auslöser der primäre ist

Ein Workflow kann mehrere Auslöser tragen, die Liste zeigt aber einen: SupaCloud bevorzugt einen aktivierten Auslöser und unter gleichrangigen den ältesten. Wichtig für die Sicht Geplant – ein Workflow, dessen einziger Auslöser ein Zeitplan ist, steht auch dann noch unter Geplant, wenn du diesen Zeitplan deaktiviert hast, denn es gibt keinen anderen Auslöser, der bevorzugt werden könnte. Geplant beschreibt, wie ein Workflow verdrahtet ist, nicht ob er gerade scharf geschaltet ist.

Einen Workflow öffnen

Ein Klick auf eine Zeile navigiert nicht weg. Er öffnet eine breite Peek-Schublade mit dem vollständigen Builder – Palette, Canvas und Eigenschaften-Panel – über der Liste, mit einer Unterzeile im Format N Knoten · N Kanten · N Auslöser. Mit Esc oder einem Klick auf den sichtbaren Streifen der Liste schließt du sie wieder und bleibst an derselben Stelle der Tabelle.

Willst du stattdessen das große Canvas, klicke Vollbild öffnen in der Kopfzeile der Schublade. Das führt zu /build/workflows/<id>, dem teilbaren Deep-Link auf einen einzelnen Workflow. Beide Oberflächen sind derselbe Editor auf denselben Daten – die Schublade ist für einen Blick, die Vollbild-Route für eine Arbeitssitzung.

Einen Lauf von Hand starten

1. Öffne den Workflow (Schublade oder Vollbild).

2. Klicke Workflow starten in der Kopfzeile des Builders. Der Lauf beginnt sofort, und das Canvas zeigt ihn an – Knotenzustände, Dauern und den Pfad, den der Lauf genommen hat.

Ein manueller Start funktioniert unabhängig davon, welche Auslöser der Workflow trägt. Du brauchst keinen Manuell-Auslöser auf dem Canvas, um den Knopf zu drücken; die Trigger-Lane regelt, was den Workflow ohne dich auslöst, nicht was du selbst starten darfst. Die einzige Stelle, die sich anders verhält, ist der Startdialog Run starten: er bietet einen Workflow nur an, wenn dessen Auslöser Manuell oder gar nicht vorhanden ist – eine bewusst enge Auswahlliste, keine Beschränkung des Workflows selbst.

Im Web-Terminal ist dasselbe eine Zeile:

workflows              # listet alle Workflows projektübergreifend auf
workflow <id>          # zeigt seine Details
workflow trigger <id>  # startet jetzt einen Lauf

Zwei Gründe, aus denen ein manueller Start abgelehnt wird

Ein Lauf von Hand ist ein Entitlement (triggers.manual) und wird zusätzlich gegen die verbleibende Run-Kapazität deines Workspace geprüft. In einem Tarif ohne manuelle Auslöser oder bei erschöpftem Budget wird der Start abgelehnt statt eingereiht – siehe Nutzung und Budget verfolgen.

Mit einer Vorlage starten

SupaCloud liefert eine Reihe fertiger Workflow-Vorlagen mit. Eine Vorlage ist kein lebendes Objekt, das du abonnierst: eine auszuwählen klont ihren Graphen in dein Projekt als gewöhnlichen, vollständig bearbeitbaren Workflow und setzt dich im Builder auf die Kopie. Danach verbindet nichts mehr die Kopie mit dem Original.

Es gibt zwei Türen zu derselben Sammlung:

• Aus Vorlage in der Aktionsleiste neben den Tabs öffnet ein Auswahlfenster.
• Der Pfeil daneben öffnet ein Überlaufmenü, dessen erster Eintrag Mit einer Vorlage starten die ganzseitige Galerie unter /build/workflows/templates ist – dieselben Vorlagen als Kacheln, mit eigener Projektauswahl.

Jede mitgelieferte Vorlage ist eine Autodev-Variante – das schlichte Autodev, der Pull-Request-Ablauf, die Tracker-Abläufe für Linear und Notion, der Git-Issue-Ablauf sowie die gegateten und die konzept-zuerst-Fassungen. Jede Kachel nennt die Trigger-Art, die sie einrichtet, und die Beschreibung sagt, was der Graph tut.

Ein geklonter Git-Auslöser kommt ausgeschaltet an

Die Autodev-Vorlagen richten ihren Git-Auslöser bewusst deaktiviert ein, damit ein halb konfigurierter Klon nicht auf echte Repository-Ereignisse zu feuern beginnt. Trage zuerst die Empfänger-URL in die Webhook-Einstellungen deines Forgejo-Repositorys ein und aktiviere den Auslöser danach in den Trigger-Eigenschaften im Builder.

Wofür diese Graphen eigentlich da sind, steht unter Den Autodev-Modus wählen und Automatisierungen.

Einen Workflow per YAML bewegen

Jeder Workflow lässt sich verlustfrei in ein server-autoritatives YAML-Dokument und zurück überführen. So kopierst du einen Workflow zwischen Projekten, prüfst eine Änderung in einem Pull Request oder hältst eine Kopie außerhalb der Plattform.

1. Öffne den Workflow und stelle den Umschalter in der Kopfzeile von Canvas auf YAML.

2. Klicke Vom Server exportieren, um den aktuell gespeicherten Graphen in den Editor zu laden – nicht deine ungespeicherten Canvas-Änderungen. Mit Kopieren legst du ihn in die Zwischenablage.

3. Um ein Dokument zurückzubringen, fügst du es in dasselbe Panel ein und klickst Als neuen Workflow importieren.

Der Import erzeugt immer eine Kopie – er speichert nie zurück

Als neuen Workflow importieren legt einen neuen Workflow im selben Projekt an und führt dich zu ihm. Es schreibt deine Änderungen nicht in den Workflow zurück, den du gerade angesehen hast – so sehr das Panel auch nach einem Editor dafür aussieht. Um den offenen Workflow zu ändern, bearbeite ihn auf dem Canvas und drücke Speichern. Um einen Workflow in ein anderes Projekt zu bringen, exportiere ihn dort und importiere ihn hier.

Das exportierte Dokument beginnt mit einer Zeile # yaml-language-server: $schema=…, die auf SupaClouds veröffentlichtes Workflow-JSON-Schema zeigt. Ein Editor, der diesen Kommentar versteht, validiert und vervollständigt die Datei damit beim Tippen. Das vollständige Vokabular aus Knoten und Kanten steht in der Workflow-YAML-Referenz.

Aus Windmill importieren

Dasselbe Überlaufmenü bietet zwei Windmill-Wege an, und sie stehen nicht gleichermaßen offen:

• Aus Windmill importieren wandelt das JSON eines einzelnen exportierten Flows in einen SupaCloud-Workflow um. Das darf jedes Workspace-Mitglied.
• Aus Repo importieren verarbeitet ein ganzes Windmill-Sync-Repository – Flows, Apps und Skripte auf einmal. Das ist eine Admin-Operation, und der Server lehnt sie für alle anderen ab, obwohl der Menüeintrag für jeden sichtbar ist. Siehe Ein Windmill-Repository importieren.

Importierte Datenbank-Bindungen sind nur lesend, bis du es änderst. Ein Schritt, der eine Postgres-Ressource als resource("f/…")-Parameter bekommen hat, wird als Code-Node mit einer Ressourcen-Bindung importiert – und der Konverter bindet sie absichtlich nur lesend (pg.query funktioniert, pg.execute wird abgelehnt). Ein schreibender Schritt – INSERT, UPDATE, DELETE oder MERGE – scheitert deshalb zur Laufzeit mit resource 'pg' is bound read-only, bis jemand den Schreibzugriff freigibt. Der Import-Bericht nennt jeden solchen Schritt. Freigeben: den Workflow im Builder öffnen, den Node auswählen und unter Eigenschaften → Ressourcen-Bindungen den Schreibzugriff dieser Bindung einschalten, dann Speichern. Der Schalter gilt je Bindung und je Node; ein Import schaltet ihn nie für dich ein. Im selben Abschnitt kannst du die Bindungen eines Nodes auch von Hand anlegen, umbinden oder entfernen.

Eine funktionierende Fassung aufbewahren

SupaCloud führt für Workflows keine Versionshistorie. Es gibt keinen Revisions-Tab, keinen Vergleich zwischen dem Graphen von gestern und dem von heute und keinen Wiederherstellen-Knopf – ein Speichern überschreibt den hinterlegten Graphen. (Skripte haben Revisionen, Workflows nicht.)

Exportiere darum vor einer riskanten Änderung das YAML und hebe es auf. Dieses exportierte Dokument ist eine vollständige, wieder importierbare Definition – das macht das YAML-Panel zur praktischen Antwort auf die Frage „Kriege ich die alte Fassung zurück?“ und ein Workflow-Verzeichnis in deinem Repository zu einer vernünftigen Gewohnheit.

Ungeleitete E-Mails

Wenn du einen Workflow an einen E-Mail-Auslöser gehängt hast, wirst du diese Seite früher oder später brauchen. Nachrichten, die an SupaClouds zentrale Trigger-Mailbox gehen, werden über den +suffix der Adresse einem Workflow zugeordnet. Was sich nicht zuordnen lässt, wird geparkt, statt für immer im Posteingang liegenzubleiben, und landet unter /build/workflows/email-unrouted.

Die Seite ist eine schlichte Tabelle der geparkten Nachrichten – Von, Betreff, Versuchte Adresse, Empfangen – mit zwei Aktionen je Zeile:

• Alias erstellen legt einen echten E-Mail-Auslöser an einem Workflow deiner Wahl an und schiebt die Nachricht zurück, sodass der nächste Poll-Zyklus diesen Workflow damit auslöst. Das ist die Reparatur „ach, die war für diesen Workflow gedacht“.
• Löschen verwirft die Nachricht.

Eine Nachricht landet hier, wenn die Adresse gar keinen +suffix trug, wenn der Suffix zu keinem Workflow-Alias passt, wenn der Alias auf einen inzwischen gelöschten oder deaktivierten Auslöser zeigt, oder wenn der Absender- oder Betreff-Filter des Auslösers sie abgewiesen hat. Der letzte Fall ist es wert, sich ihn zu merken: eine ausgefilterte Nachricht wird nicht still verworfen, sondern geparkt.

Nur für Admins – und von nirgends verlinkt

Geparkte Nachrichten zu lesen, umzuleiten und zu löschen erfordert jeweils die Rolle Workspace-Admin; ein Mitglied bekommt eine Fehlermeldung wegen fehlender Berechtigung. Die Seite ist außerdem weder aus der Navigation noch aus der Workflow-Liste verlinkt – du erreichst sie, indem du /build/workflows/email-unrouted eingibst oder als Lesezeichen ablegst. Ist in deiner Instanz keine zentrale Mailbox konfiguriert, bleibt die Liste einfach leer.

Für die Trigger-Variante, bei der du dein eigenes Postfach abfragst, siehe IMAP-Trigger einrichten.

Einen Workflow stilllegen, ohne ihn zu löschen

Es gibt keinen Ein-/Aus-Schalter am Workflow selbst. Was du abschaltest, ist das, was ihn auslöst:

1. Öffne den Workflow und wähle seinen Auslöser in der Trigger-Lane aus.

2. Schalte im Eigenschaften-Panel des Auslösers Aktiviert aus.

3. Wiederhole das für jeden Auslöser, den der Workflow trägt – die Spalte Auslöser der Liste zeigt immer nur einen davon.

Ein Workflow, dessen Auslöser alle deaktiviert sind, behält seinen Graphen, seinen Namen und seine gesamte Lauf-Historie, reagiert nicht mehr auf Ereignisse und lässt sich weiterhin über Workflow starten von Hand starten. Genau diese Kombination willst du, während du ihn reparierst.

Zwei verwandte Drosseln:

• Wird der Workflow von einem Zeitplan ausgelöst, ist das Pausieren dieses Zeitplans der sauberere Stopp – siehe Einen Zeitplan einrichten.
• Das Zahnrad in der Builder-Kopfzeile setzt für diesen Workflow ein Limit gleichzeitiger Ausführungen. Leer lassen heißt unbegrenzt; überzählige Läufe werden in die Warteschlange gestellt und gestartet, sobald Slots frei werden, statt verworfen zu werden.

Einen Workflow löschen

Das Papierkorb-Symbol am rechten Rand einer Zeile löscht auf dem Desktop diesen Workflow, abgesichert durch die Bestätigung Workflow löschen. (Die Telefonkarte hat keinen Löschknopf – ein Tippen öffnet dort den Builder.) Jedes Workspace-Mitglied darf löschen, eine Admin-Rolle ist nicht nötig, und ein noch laufender Run blockiert das Löschen nicht – dieser Run wird mit allem anderen zusammen entfernt.

Ein Workflow zu löschen löscht auch seine Lauf-Historie

Das Löschen kaskadiert in der Datenbank: die Knoten und Kanten des Graphen, jeder Auslöser, die aus diesen Auslösern abgeleiteten E-Mail-Aliase, jeder Zeitplan, der diesen Workflow auslöst, und jeder Lauf davon – samt den Läufen seiner einzelnen Knoten – werden mitentfernt. Bis vor Kurzem behauptete der Bestätigungsdialog das Gegenteil („vergangene Läufe bleiben erhalten”); er nennt jetzt, was tatsächlich verschwindet.

Bevor du etwas löschst, worüber du später Rechenschaft ablegen willst: exportiere das YAML (siehe oben) und lies vorher aus der Lauf-Historie, was du brauchst. Soll er nur aufhören zu feuern, deaktiviere stattdessen seine Auslöser – dabei bleibt alles erhalten.

Wo die Läufe landen

Die Liste erzählt dir über Läufe; gelesen werden sie woanders. Jede Ausführung – von Hand gestartet, durch einen Zeitplan, einen Webhook oder eine eingehende Mail – ist ein Run unter Runs, mit dem Workflow-Run als Elternteil und der Ausführung jedes Knotens als Kind-Run darunter. Öffne dort einen Run für das vollständige Ereignisprotokoll, die Zeiten je Knoten und jede Freigabe, auf die er wartet.

Siehe auch

• Deinen ersten Workflow erstellen – Canvas, Palette und Trigger-Lane.
• Runs und Tasks – warum Definition und Ausführung getrennte Dinge sind.
• Befehle des Web-Terminals – workflows, workflow <id>, workflow trigger <id>.
• Einen Zeitplan einrichten – der zeitgesteuerte Weg, einen Workflow auszulösen.