Ereignisse, Filter und Bedingungen

Ereignisse, Filter und Bedingungen

0:00 Unser Workflow läuft. Jetzt kommt die Frage, die im Alltag mehr Ärger macht als jede andere: Wann soll er eigentlich laufen — und wann besser nicht? Eine Pipeline, die bei jeder Kleinigkeit anspringt, verstopft die Warteschlange und wird irgendwann ignoriert. Eine, die zu selten anspringt, prüft die falschen Dinge. In diesem Modul lernen Sie die Auslöser kennen, ihre Filter nach Branch, Tag und Pfad, die manuellen und zeitgesteuerten Varianten — und am Ende die Bedingungen, mit denen einzelne Jobs entscheiden, ob sie überhaupt etwas tun.

0:31 Dabei kommt auch das erste ernste Sicherheitsthema dieses Seminars zur Sprache: Beiträge aus fremden Forks.

Ereignisse, Filter und Bedingungen

0:38 Drittes Modul des ersten Tages. Wir arbeiten uns von außen nach innen: erst die Ereignisse, die einen ganzen Workflow starten, dann die Sonderfälle manuell und zeitgesteuert, zuletzt die Bedingungen innerhalb des Laufs. Am Ende schneiden Sie die Auslöser der Beetkarte so zu, dass Sie zu jedem Lauf in der Übersicht sagen können, warum es ihn gibt.

Auslöser für Workflows

0:58 Beginnen wir mit den beiden Ereignissen, die neunzig Prozent aller Fälle abdecken — und mit den Filtern, die aus einem groben Auslöser einen präzisen machen. Zwei Ereignisse tragen den Alltag: der Push und der Pull Request. Beide lassen sich einschränken — nach Branch, nach Tag und nach den geänderten Pfaden. Ohne Filter läuft der Workflow bei jeder Änderung an jedem Branch, und das ist selten gewollt.

1:21 Denken Sie an eine Türklingel, die bei jedem Passanten läutet: technisch korrekt, praktisch unbrauchbar. Die Filter sind das, was aus dem Signal eine Information macht. Und sie sind der erste Hebel gegen zu lange Warteschlangen, noch vor jeder Optimierung der Laufzeit selbst. Hier sehen Sie drei Entscheidungen auf einmal. Der Push wird auf den Hauptbranch und auf Versions-Tags begrenzt — Letztere lösen später unseren Release aus.

1:47 Der Pull Request wird auf den Hauptbranch als Ziel eingeschränkt. Und dann die Ausnahmen: Änderungen an der Dokumentation und an Markdown-Dateien lösen keinen Lauf aus. Achten Sie auf eine Feinheit: Es gibt zwei Varianten des Pfadfilters — eine, die einschließt, und eine, die ausschließt. Beide zusammen in einem Ereignis sind ungültig.

2:07 Sie müssen sich also entscheiden, ob Sie die Ausnahmen oder die Regel beschreiben. Vier Gründe, und der dritte ist eine Falle, in die viele erst spät tappen. Jeder unnötige Lauf belegt einen Runner, den ein nötiger gerade braucht — das merkt man zu Stoßzeiten sofort. Ein Workflow, der bei jeder Textänderung anspringt, wird bald weggeklickt statt gelesen.

2:28 Und jetzt der heikle Punkt: Wenn Sie eine Prüfung als Voraussetzung für den Merge hinterlegen, sie aber durch einen Pfadfilter gar nicht startet, bleibt der Pull Request hängen — ausgelassen ist eben nicht dasselbe wie grün. Wir kommen in Modul sieben darauf zurück. Der erste Punkt ist der häufigste und der teuerste: Push und Pull Request auf demselben Branch lassen jeden Commit zweimal laufen — doppelte Kosten, doppelte Wartezeit, und niemand merkt es, weil beide Läufe grün sind.

2:56 Der zweite ist bitter: Ausgerechnet die Datei, die den Fehler enthielt, war vom Filter ausgeschlossen. Der dritte überrascht regelmäßig — Branch-Filter greifen bei Tags nicht, ein Tag-Push löst dann schlicht nichts aus. Und beim vierten geht es um Mustersyntax, bei der ein Sternchen mehr oder weniger den Unterschied macht.

Manuelle, zeitgesteuerte und weitere Ereignisse

3:15 Nicht jeder Lauf beginnt mit einem Commit. Manche starten auf Knopfdruck, manche nach der Uhr, manche durch ein Ereignis irgendwo im Repository. Sehen wir uns an, welche das sind und wofür sie taugen. Der manuelle Auslöser ist unterschätzt: Er macht einen Workflow über die Oberfläche oder die Schnittstelle startbar und nimmt dabei typisierte Eingaben entgegen — also nicht nur Freitext, sondern echte Auswahllisten, Wahrheitswerte oder Umgebungen.

3:42 Genau das brauchen wir später für Deployments. Daneben gibt es zeitgesteuerte Läufe nach Cron-Syntax und Ereignisse für Releases, Issues, Kommentare und vieles mehr. Der Reflex, alles an den Push zu hängen, führt zu Workflows, die dauernd laufen. Manches gehört an einen Knopf, manches an die Uhr. Zwei Eingaben, zwei verschiedene Typen — und beide sind bewusst keine freien Textfelder.

4:06 Die eine ist vom Typ Umgebung, die andere eine Auswahlliste mit genau zwei erlaubten Werten. Warum das wichtig ist, sehen Sie in Modul dreizehn: Alles, was ein Mensch frei eintippen kann, ist eine Eingabe von außen — und wenn sie ungeprüft in ein Kommando wandert, haben Sie eine Sicherheitslücke gebaut. Eine Auswahlliste schließt das von vornherein aus. Nebenbei ist sie auch bedienungsfreundlicher: Niemand muss sich merken, wie die Umgebung genau geschrieben wird.

4:33 Die Tabelle sortiert nach der Frage, wer den Anstoß gibt: Bei den ersten beiden ist es eine Codeänderung, beim dritten ein Mensch, beim vierten die Uhr, beim fünften ein Vorgang im Repository. Eine Warnung zum zeitgesteuerten Lauf, die in der Dokumentation leicht zu überlesen ist: Er startet nicht auf die Minute genau, und in Repositories ohne Aktivität pausiert er irgendwann ganz.

4:54 Für eine nächtliche Aufräumaufgabe ist das egal, für etwas Zeitkritisches sollten Sie es wissen — und keinesfalls annehmen, dass ein solcher Lauf garantiert stattfindet. Der erste Punkt beschert Ihnen zweimal im Jahr Verwirrung: Cron-Ausdrücke sind in koordinierter Weltzeit angegeben, Ihre Sommerzeit interessiert das nicht.

5:13 Der zweite ist ein echter Klassiker — der manuelle Auslöser erscheint in der Oberfläche erst, wenn die Datei auf dem Standardbranch liegt; auf einem Feature-Branch suchen Sie den Knopf vergeblich. Der dritte ist eine Frage der Höflichkeit gegenüber der Infrastruktur: Alle nächtlichen Läufe stehen auf null Uhr und treffen dort auf die Warteschlange der ganzen Welt.

5:32 Und der vierte führt uns direkt zum nächsten Kapitel.

Bedingungen und sichere Trigger

5:36 Bis hierhin ging es darum, ob ein Workflow startet. Jetzt geht es darum, was innerhalb des Laufs überhaupt ausgeführt wird — und um einen Auslöser, bei dem Vorsicht angebracht ist. Mit einer Bedingung entscheidet ein Job oder ein Schritt zur Laufzeit, ob er etwas tut. Dazu gibt es Statusfunktionen, die sich auf den bisherigen Verlauf beziehen: erfolgreich, fehlgeschlagen, abgebrochen oder immer.

5:59 Wichtig ist die stille Voreinstellung: Ohne Bedingung läuft ein Schritt nur, solange nichts fehlgeschlagen ist. Das klingt selbstverständlich, hat aber eine Konsequenz — Ihr Aufräumschritt oder der Schritt, der den Testbericht sichert, läuft nach einem Fehler genau dann nicht, wenn Sie ihn am dringendsten bräuchten. Zwei Anwendungen auf einen Blick.

6:19 Oben eine Bedingung am Job: Er läuft nur, wenn wir uns auf dem Hauptbranch befinden — das ist die einfachste Form eines Schutzes vor versehentlichen Deployments. Unten eine am Schritt: Der Bericht wird auch dann gesichert, wenn der Test vorher gescheitert ist. Und ein Detail, das regelmäßig für Verwirrung sorgt: In der Bedingung stehen die geschweiften Klammern nicht, denn GitHub wertet den Ausdruck an dieser Stelle ohnehin aus.

6:43 Schreiben Sie sie trotzdem, funktioniert es meist — aber nicht immer. Jetzt der Punkt, an dem schon viele Projekte kompromittiert wurden. Bei einem normalen Pull Request aus einem Fork bekommt der Lauf nur Leserechte und keine Geheimnisse — GitHub schützt Sie hier von sich aus. Es gibt aber eine Variante des Auslösers, die im Kontext Ihres eigenen Repositories läuft, mit Schreibrechten und Zugriff auf die Geheimnisse.

7:07 Wer darin den Code aus dem Fork auscheckt und ausführt, führt fremden Code mit vollen Rechten aus. Das ist keine Theorie, das ist ein bekannter Angriffsweg. Die sichere Reihenfolge: erst prüfen ohne Geheimnisse, dann in einem getrennten Lauf veröffentlichen. Der erste Punkt ist tückisch: Eine Bedingung, die versehentlich als Zeichenkette geschrieben wird, ist immer wahr — der Schutz greift nie, und Sie merken es nicht, weil ja alles läuft.

7:33 Der zweite betrifft die Statusfunktion, die immer ausführt; sie überdeckt auch einen Abbruch, und dann läuft ein Schritt weiter, den Sie gerade stoppen wollten. Der dritte ist eine Reihenfolgefrage mit Sicherheitsfolgen: Prüft der Job den Branch erst in einem Schritt, sind die Geheimnisse längst geladen. Und der vierte kostet Nerven bei der Fehlersuche.

Übung

7:52 Jetzt schneiden Sie die Auslöser der Beetkarte zu. Das Ziel ist ungewöhnlich formuliert, aber genau richtig: Sie sollen zu jedem Lauf in der Übersicht sagen können, warum es ihn gibt. Vier Workflows, vier verschiedene Anlässe: Der Test gehört an den Pull Request, die Dokumentation an ihren eigenen Pfad, der Release an den Tag, das Deployment an den Knopf.

8:13 Der Nachweis ist erfreulich einfach — ein Blick in die Actions-Ansicht nach ein paar Commits. Wenn dort ein Lauf steht, den Sie nicht erklären können, ist die Aufgabe noch nicht fertig. Und dann noch der Fork-Fall: Öffnen Sie gedanklich oder tatsächlich einen Pull Request aus einem Fork und prüfen Sie, welche Läufe dabei starten und welche Rechte sie hätten.

8:34 Die vier Schnitte gehen vom Alltäglichen zum Besonderen. Erst der Testlauf, eingegrenzt auf Pull Requests gegen den Hauptbranch. Dann die Dokumentation ausnehmen — und danach unbedingt prüfen, ob die Prüfung, die den Merge blockiert, dadurch noch startet. Der Release-Workflow wird allein an Tags gebunden, damit er nicht bei jedem Push mitläuft.

8:54 Und zum Schluss ein Deployment-Workflow mit manueller Auslösung und Auswahl der Zielstufe — den brauchen wir in Modul elf wieder, dann mit echten Schutzregeln dahinter. Der erste Punkt ist der, der Sie in der Übung am wahrscheinlichsten trifft: Der Pfadfilter macht eine erforderliche Prüfung unerfüllbar, und der Pull Request hängt ohne sichtbaren Grund fest.

9:15 Der zweite ist die Sicherheitsfalle aus dem letzten Kapitel — eine manuelle Eingabe, die ungeprüft in ein Kommando geht. Der dritte ist die doppelte Auslösung, diesmal beim Release. Und der vierte ist eine Frage der Disziplin: Nach jeder Änderung an den Auslösern kurz nachsehen, ob die gewollten Läufe noch starten. Im nächsten Modul geht es dann um die Werte, die zwischen diesen Läufen wandern.