Workflows und Actions wiederverwenden

Workflows und Actions wiederverwenden

0:00 Dieselbe Schrittfolge in zwölf Repositories ist kein Standard — das sind zwölf Gelegenheiten, unterschiedlich zu altern. Genau da setzt dieses Modul an. GitHub Actions kennt zwei Wege, Wiederholung zu vermeiden, und sie werden häufig verwechselt: wiederverwendbare Workflows, die ganze Jobs kapseln, und Composite Actions, die Schritte bündeln.

0:20 Wir sehen uns beide an, klären, welcher wofür taugt, und sprechen dann über das, was in Organisationen daraus wird: zentrale Pipeline-Repositories, Vorlagen und die Frage, wie man eine gemeinsame Pipeline ändert, ohne alle gleichzeitig lahmzulegen.

Workflows und Actions wiederverwenden

0:35 Viertes Modul des zweiten Tages. Erst die wiederverwendbaren Workflows mit ihren Eingaben, Geheimnissen und Grenzen, dann die Composite Actions, dann die organisatorische Ebene. Am Ende liegt die Prüfpipeline der Beetkarte als Baustein vor, den zwei Repositories aufrufen — und Sie können begründen, warum welcher Teil Workflow und welcher Action geworden ist.

Reusable Workflows

0:56 Beginnen wir mit dem größeren der beiden Werkzeuge. Ein wiederverwendbarer Workflow ist ein vollständiger Workflow, der sich von anderen aufrufen lässt — mit Parametern, wie eine Funktion. Der Mechanismus ist schnell erklärt: Ein Workflow bekommt einen besonderen Auslöser, der ihn aufrufbar macht, und nimmt Eingaben, Geheimnisse und Ausgaben entgegen.

1:18 Aufgerufen wird er auf Jobebene — das ist wichtig, denn er ersetzt einen Job, nicht einen Schritt. Die Referenz besteht aus Besitzer, Repository, Pfad und einer Angabe, welche Fassung Sie wollen: ein Tag, ein Branch oder ein Commit. Diese letzte Angabe ist die Stelle, an der später vieles entschieden wird — sie bestimmt, ob Änderungen bei Ihnen automatisch ankommen oder erst nach einer bewussten Entscheidung.

1:42 So sieht die Schnittstelle des Bausteins aus. Oben die Eingabe — hier die Node-Version, als Zeichenkette, denn als Typen stehen nur Zeichenkette, Zahl und Wahrheitswert zur Verfügung. Unten die Ausgabe, die auf eine Job-Ausgabe innerhalb des Workflows verweist; das ist derselbe Mechanismus wie in Modul vier, nur eine Ebene höher.

2:01 Denken Sie beim Entwerfen dieser Schnittstelle daran, dass sie später Dutzende Aufrufer hat. Ein Eingabename, den Sie ändern, bricht sie alle gleichzeitig — Schnittstellen wollen von Anfang an gut überlegt sein. Der Aufruf steht auf Jobebene, nicht bei den Schritten — das ist der Fehler, den man beim ersten Mal garantiert macht.

2:20 Interessant ist die letzte Zeile: Mit dem Vererben werden alle Geheimnisse durchgereicht, was bequem ist und nur innerhalb derselben Organisation funktioniert. Bequemlichkeit hat hier allerdings ihren Preis: Der aufgerufene Workflow sieht damit auch Geheimnisse, die er gar nicht braucht. Bei einem Baustein aus einem anderen Team ist die einzelne Übergabe die bessere Wahl, auch wenn sie mehr Zeilen kostet. Und beachten Sie das Versions-Tag am Ende der Referenz.

2:47 Vier Grenzen, die im Alltag tatsächlich vorkommen. Sie können bis zu zehn Ebenen verketten — das reicht für jede sinnvolle Struktur und noch für einige unsinnige. Geheimnisse erreichen immer nur den direkt aufgerufenen Workflow; in einer Kette müssen sie an jeder Stufe weitergereicht werden, sonst kommen sie unten nicht an.

3:05 Berechtigungen lassen sich senken, aber nie anheben — ein aufgerufener Workflow kann sich nicht mehr Rechte verschaffen als sein Aufrufer hat. Und der Schlüssel für Umgebungen steht im Aufruf nicht zur Verfügung; das trifft Deployment-Bausteine. Der erste Punkt ist der teuerste, den dieses Modul kennt: Alle Repositories zeigen auf einen Branch, jemand committet dorthin, und die ganze Organisation steht.

3:28 Der zweite und dritte sind Anfängerfehler mit klarer Fehlermeldung — fehlendes Geheimnis, Aufruf an falscher Stelle. Der vierte ist tückischer: Das Repository mit den Bausteinen ist für die aufrufenden Repositories nicht sichtbar. Das passiert typischerweise, wenn ein privates Pipeline-Repository entsteht und die Freigabe erst später jemandem auffällt.

Composite Actions

3:49 Jetzt das kleinere Werkzeug. Eine Composite Action bündelt Schritte, die sich dann wie ein einziger Schritt verhalten — deutlich leichtgewichtiger als ein eigener Workflow. Eine Composite Action ist eine Beschreibungsdatei mit einer Liste von Schritten. Sie wird innerhalb eines Jobs eingebunden und läuft auf dessen Maschine — sie bekommt also keinen eigenen Runner.

4:10 Das ist der zentrale Unterschied zum wiederverwendbaren Workflow und entscheidet die Wahl zwischen beiden. Eine Eigenheit, über die jeder einmal stolpert: Jeder Kommandoschritt darin muss die Shell ausdrücklich angeben. In einem normalen Workflow ist sie voreingestellt, hier nicht — und die Action lässt sich ohne diese Angabe gar nicht erst laden.

4:29 Das ist unser Kandidat: die immer gleiche Einrichtung aus Node-Version, Cache und Installation. Diese drei Schritte stehen sonst in jedem Workflow und jedem Job erneut — und wenn Sie die Node-Version anheben wollen, ändern Sie sie an zwölf Stellen. Als Action ändern Sie sie an einer. Beachten Sie, dass die Node-Version als Eingabe hereinkommt, statt fest verdrahtet zu sein: Damit bleibt die Action für die Matrix aus Modul fünf brauchbar.

4:54 Und für eine Ausgabe bräuchte es hier zusätzlich einen Verweis auf den erzeugenden Schritt. Diese Gegenüberstellung ist die Entscheidungshilfe des Moduls. Links das Werkzeug für ganze Jobs, rechts das für Schrittfolgen. Die dritte und vierte Zeile enthalten das eigentliche Kriterium: Wenn Sie einen eigenen Runner, eine Matrix oder eine Umgebung brauchen, ist es ein Workflow.

5:17 Wenn Sie nur eine wiederkehrende Handgriffsfolge kapseln, ist es eine Action. In der Praxis kombiniert man beides — der wiederverwendbare Workflow ruft intern die Composite Action auf. Genau so bauen wir es gleich in der Übung. Der erste Punkt ist die eben erwähnte Shell-Angabe, die genau einmal Lehrgeld kostet. Der zweite ist ein Entwurfsproblem: Eine Action, die stillschweigend voraussetzt, dass bestimmte Werkzeuge schon installiert sind, funktioniert im einen Projekt und im anderen nicht.

5:46 Der dritte ist ein Sicherheitsthema — Geheimnisse als Eingaben landen im Aufrufprotokoll. Und der vierte ist die typische Alterung: Aus einer schlanken Action wird über Monate ein Gebilde mit Sonderfällen für jedes Team, und am Ende versteht sie niemand mehr.

Organisationsweite Standards

6:00 Aus zwei Repositories werden zwanzig. Damit wird aus einer technischen Frage eine organisatorische: Wem gehört die Pipeline, und wie ändert man sie, ohne alle stillzulegen? Auf Organisationsebene gibt es Vorlagen für neue Workflows, hinterlegt in einem besonderen Repository. Zusammen mit einem zentralen Pipeline-Repository und versionierten Bausteinen entsteht daraus ein Golden Path: der Weg, den ein neues Projekt geht, ohne dass jemand nachdenken muss.

6:28 Wichtig ist der Unterschied zwischen beiden Mitteln: Eine Vorlage wird einmal kopiert und lebt danach ihr eigenes Leben. Ein wiederverwendbarer Workflow bleibt eine Abhängigkeit — jede Änderung wirkt sofort bei allen. Das ist Stärke und Risiko in einem. Der rote Faden dieser fünf Schritte ist: Änderungen dürfen niemanden überraschen. Bausteine gehören in ein eigenes Repository und werden mit Tags versioniert.

6:53 Aufrufer zeigen auf einen Hauptversions-Tag, nicht auf einen Branch — das ist der wichtigste Schritt überhaupt. Änderungen werden erst in einem Pilotprojekt erprobt, und der Hauptversions-Tag wird erst nachgezogen, wenn dort mehrere Läufe grün sind. Brüche bekommen eine neue Hauptversion, und die alte läuft befristet weiter. Und ohne einen Weg, die Teams zu informieren, ist jede Umstellung ein Überraschungsausfall.

7:18 Die Trennlinie verläuft zwischen dem, was überall gleich sein soll, und dem, was am einzelnen Dienst hängt. Build- und Prüfschritte, Sicherheitsvorgaben und Freigabewege gehören zentral. Alles Fachliche bleibt lokal. Und dann der Satz, der oft vergessen wird: Wer zentral vorgibt, übernimmt auch die Verantwortung für den Ausfall.

7:37 Ein Plattformteam, das Bausteine bereitstellt, aber bei einem Problem auf die Projektteams verweist, verliert deren Vertrauen schnell — und dann kopieren alle wieder ihre eigene Fassung. Der erste und der dritte Punkt sind die beiden Enden desselben Scheiterns: Entweder wächst der gemeinsame Workflow um so viele Sonderfälle, dass ihn niemand mehr versteht, oder alle kopieren ihn und driften auseinander.

8:00 Der zweite ist der Ausfall, über den wir eben gesprochen haben. Und der vierte wird meist erst im Ernstfall entdeckt: Es gibt keinen Weg zurück auf die vorherige Version, weil die alten Tags gelöscht wurden oder nie existiert haben.

Übung

8:12 In der Übung wird aus der Pipeline der Beetkarte ein Baustein — und Sie treffen dabei zweimal die Entscheidung zwischen Workflow und Action. Zwei Auslagerungen, ein Nachweis. Build und Test wandern in einen wiederverwendbaren Workflow, der aus zwei Repositories mit verschiedenen Eingaben aufgerufen wird. Die wiederkehrende Einrichtung wird zur Composite Action. Und der Hinweis am Ende ist ausdrücklich Teil der Aufgabe: Der Aufruf zeigt auf ein Tag, nicht auf einen Branch.

8:40 Es ist verlockend, während der Übung einfach auf den Hauptbranch zu zeigen, weil man dann schneller iteriert — aber genau diese Gewohnheit wird später zum Ausfall. Üben Sie es gleich richtig. Die Schritte eins bis drei bauen den Workflow-Baustein, Schritt vier die Action. Wichtig ist Schritt fünf, und der besteht aus Nachdenken statt Tippen: Warum ist das eine ein Workflow und das andere eine Action geworden?

9:04 Die Antwort steht im Diagramm von vorhin — der Testjob braucht einen eigenen Runner und später eine Matrix, die Einrichtung braucht beides nicht. Wenn Sie diese Begründung sauber formulieren können, haben Sie das Modul verstanden; alles andere ist Handwerk. Der erste Punkt ist der häufigste Entwurfsfehler in diesem Modul: Eine Composite Action wird gebaut, wo eigentlich ein eigener Job nötig wäre — und dann fehlt plötzlich die Möglichkeit, eine Matrix zu verwenden.

9:31 Der zweite ist ein Flüchtigkeitsfehler mit stiller Wirkung: Die Ausgabe ist deklariert, aber im Job nie gesetzt. Der dritte ist die Branch-Referenz, vor der wir gewarnt haben. Und der vierte ist der menschliche: Teilen ist mühsamer als kopieren, und die Kopie rächt sich erst Monate später. Im nächsten Modul bauen wir dann eine eigene Action von Grund auf.