Den ersten Workflow erstellen

Den ersten Workflow erstellen

0:00 Im ersten Modul haben wir aufgeschrieben, was heute von Hand passiert. Jetzt automatisieren wir den ersten Teil davon. Am Ende dieses Moduls hat die Beetkarte einen Workflow, der bei jedem Pull Request auscheckt, installiert, baut und testet — und Sie können ein rotes Ergebnis aus dem Log heraus erklären. Das klingt bescheiden, ist aber der Kern: Alles Weitere, von Matrix Builds bis zu abgesicherten Deployments, ist eine Erweiterung genau dieser Datei.

0:25 Wir sehen uns außerdem an, warum diese Datei im Repository liegt und nicht in einer Oberfläche — das ist ein Unterschied, der im Alltag mehr ausmacht, als er zunächst scheint.

Den ersten Workflow erstellen

0:36 Wir bleiben im ersten Tag und werden konkret. Vier Kapitel: der Aufbau der Datei, die Bausteine Jobs, Schritte und Runner, das Beobachten der Läufe — und dann bauen Sie den Workflow selbst. Der erste rote Lauf gehört ausdrücklich dazu; wir lassen ihn absichtlich scheitern, denn das Lesen eines Fehlers ist die Fähigkeit, die Sie danach jeden Tag brauchen.

Aufbau einer Workflow-Datei

0:57 Beginnen wir mit dem Rahmen. Eine Workflow-Datei hat erstaunlich wenige Pflichtangaben — und einen festen Ort, an dem sie liegen muss, sonst passiert schlicht gar nichts. Workflows liegen unter Punkt-github, Schrägstrich, workflows. Dieser Pfad ist nicht verhandelbar, und das ist der erste Fehler, den fast jeder einmal macht: Ein Buchstabe daneben, und die Datei wird ignoriert — ohne Fehlermeldung, denn GitHub sieht dort ja nichts.

1:23 Pflicht sind zwei Angaben: ein Auslöser und mindestens ein Job. Alles andere ist Komfort. Der Name erscheint in der Actions-Ansicht, und der Run-Name benennt den einzelnen Lauf. Das klingt nach Kosmetik, wird aber wichtig, sobald zwanzig Läufe untereinanderstehen und Sie den einen suchen, der Ihre Änderung geprüft hat. Hier sehen Sie den Kopf unserer Datei — und schon die erste inhaltliche Entscheidung. Wir lassen den Workflow bei Pushes auf den Hauptbranch laufen und bei jedem Pull Request.

1:53 Warum beides? Weil der Pull Request die Änderung prüft, bevor sie hineinkommt, und der Push auf den Hauptbranch bestätigt, dass die Zusammenführung selbst nicht kaputt gegangen ist. Der Run-Name greift auf einen Kontextwert zu, in dem GitHub den Branchnamen bereitstellt — mehr dazu in Modul vier. Merken Sie sich das Muster mit den doppelten geschweiften Klammern; es wird uns überall begegnen.

2:16 Das ist ein Punkt, den Umsteiger von älteren Werkzeugen oft unterschätzen. Wenn die Automatisierung neben dem Code liegt, ändert sie sich mit ihm — im selben Pull Request, mit demselben Review. Sie können auf einem Branch eine neue Fassung erproben, ohne dass jemand anders davon betroffen ist. Die Historie beantwortet Monate später, wann eine Prüfung dazukam und wer sie wieder entfernt hat. Und ein Fork bringt die Automatisierung mit, statt dass jemand sie nachbaut.

2:43 Der Preis dafür: Eine Änderung an dieser Datei ist eine Änderung an Produktionscode. Wir kommen in Modul dreizehn darauf zurück. Die ersten beiden Punkte kosten typischerweise eine halbe Stunde und etwas Nerven. Ein fehlendes s im Verzeichnisnamen führt dazu, dass gar nichts passiert — und weil nichts passiert, gibt es auch nichts zu lesen.

3:04 Tabulatoren in YAML sind ein Klassiker; YAML verbietet sie, und die Fehlermeldung ist selten hilfreich. Der dritte Punkt wird erst später schmerzhaft, wenn zehn Läufe gleich heißen. Und der vierte ist der stille: Ein Workflow ohne passenden Auslöser wartet auf ein Ereignis, das in Ihrem Projekt nie eintritt.

Jobs, Schritte und Runner

3:23 Vom Rahmen zum Inhalt. In diesem Kapitel füllen wir den Job mit Schritten — und lernen den wichtigsten Unterschied kennen: eigenen Code ausführen oder fremden einbinden. Ein Job wählt seine Maschine und arbeitet darauf eine Liste von Schritten ab. Ein Schritt ist entweder ein Kommando oder eine fertige Action — beides in einem Schritt geht nicht.

3:43 Und jetzt die Stelle, an der jeder erste Workflow scheitert: Der Arbeitsbereich ist zu Beginn leer. GitHub legt Ihnen Ihr Repository nicht automatisch auf die Maschine. Auch das eigene Projekt muss erst ausgecheckt werden, mit einer ganz gewöhnlichen Action. Wenn Ihnen also ein Kommando meldet, es finde keine package-Datei, ist das fast immer die Erklärung.

4:04 Vier Schritte, und die Pipeline steht: auschecken, Node einrichten, installieren, testen. Zwei Dinge lohnen einen zweiten Blick. Erstens die Node-Version — sie steht ausdrücklich da, und das ist Absicht: Ohne Angabe nehmen Sie, was zufällig auf dem Runner-Image liegt, und das ändert sich mit der Zeit. Zweitens das Installationskommando. Es installiert exakt die Stände aus der Sperrdatei und bricht ab, wenn diese nicht zum Manifest passt.

4:29 Genau das wollen Sie in einer Pipeline: keine Überraschungen, sondern denselben Stand wie bei allen anderen im Team. Diese fünf Schlüssel decken die allermeisten Schritte ab, die Sie je schreiben werden. Wichtig ist das Verhältnis der beiden ersten: Der eine bindet fremden Code ein, der andere führt eigenen aus — und sie schließen sich innerhalb eines Schritts gegenseitig aus.

4:51 Der dritte reicht Eingaben an eine Action weiter. Die letzten beiden wirken nebensächlich, sind es aber nicht: Ein Anzeigename macht das Log lesbar, und ohne Kennung können Sie später nicht auf die Ausgabe eines Schritts zugreifen. Das ist der häufigste Grund, warum die Wertweitergabe in Modul vier nicht funktioniert. Der erste Punkt ist der Klassiker, den wir eben besprochen haben. Der zweite überrascht viele: Jeder Schritt startet in einer neuen Shell.

5:17 Ein Verzeichniswechsel im einen Schritt wirkt im nächsten nicht mehr, und eine dort gesetzte Variable ist ebenfalls weg — dafür gibt es eigene Mechanismen, die wir in Modul vier kennenlernen. Der dritte Punkt sorgt für die berühmte Antwort „bei mir läuft es". Und der vierte macht die Fehlersuche unnötig mühsam: Schritte ohne Namen sind im Log nur an ihrem Kommando zu erkennen.

Läufe beobachten und Fehler nachvollziehen

5:38 Ein Workflow, der durchläuft, ist die eine Hälfte. Die andere ist der Umgang mit dem Lauf, der es nicht tut — und da entscheidet sich, ob eine Pipeline dem Team hilft oder es nur beschäftigt. Jeder Lauf erscheint in der Actions-Ansicht mit seinen Jobs und Schritten, und jedes Log lässt sich aufklappen und herunterladen. Sie können einen kompletten Lauf erneut starten oder nur die gescheiterten Jobs — und dieser Unterschied ist mehr als eine Bequemlichkeit.

6:05 Er verrät Ihnen nämlich etwas: Wenn ein Job beim zweiten Versuch mit demselben Stand grün wird, liegt es nicht am Code. Wichtig zu wissen: Ein erneuter Lauf verwendet immer denselben Commit. Er ist ein Diagnosewerkzeug, kein Ersatz für eine Korrektur. Der rote Faden dieser vier Schritte heißt: Ursache vor Symptom. Öffnen Sie den ersten roten Schritt, nicht den letzten — alles danach sind meist Folgefehler.

6:29 Dann die entscheidende Frage: Ist es der Code oder die Umgebung? Wenn es lokal mit derselben Version läuft, suchen Sie an der falschen Stelle. Erst beim Verdacht auf ein Zeitproblem lohnt der erneute Start eines einzelnen Jobs. Und bleibt es unklar, gibt es das ausführliche Protokoll, das Sie über ein Geheimnis einschalten. In dieser Reihenfolge sparen Sie sich viel Warten.

6:52 Der erneute Start ist ein diagnostisches Werkzeug, kein Reflex. Wird der Lauf grün, hängt der Test an Zeit, Reihenfolge oder Netz — und das ist ein echter Befund, dem Sie nachgehen sollten, nicht ein glücklicher Zufall. Bleibt er rot, steckt der Fehler im Code oder der Konfiguration. Gefährlich wird es, wenn das Neustarten zur Gewohnheit wird: Dann gewöhnt sich ein Team daran, dass Rot nichts bedeutet — und übersieht irgendwann den einen Fehler, der echt war.

7:19 Wir sprechen in Modul sechzehn darüber, wie man das an Kennzahlen erkennt. Der erste Punkt ist die eben beschriebene Gewohnheit in ihrer schlimmsten Form. Der zweite überrascht im Ernstfall: Logs verschwinden mit der Aufbewahrungsfrist, und wer den Fehler vom letzten Monat belegen will, findet nichts mehr. Der dritte passiert, wenn ein Aufräumschritt am Ende die eigentliche Fehlermeldung überschreibt — dann steht im Log das Aufräumen und nicht das Problem.

7:44 Und der vierte ist der gefährlichste: Ein Schritt verschluckt den Rückgabewert, der Job gilt als erfolgreich, und die Pipeline meldet Grün für etwas, das nie funktioniert hat.

Übung

7:54 Genug Theorie. Sie bauen jetzt den ersten Workflow der Beetkarte — inklusive des Fehlers, den wir absichtlich einbauen, damit Sie ihn im Log lesen können. Das Ziel ist ein Workflow, der bei jedem Pull Request auscheckt, installiert, baut und testet. Der interessante Teil kommt danach: Lassen Sie den Build-Schritt weg und schauen Sie sich an, was passiert.

8:16 Manche Projekte melden dann einen klaren Fehler, andere laufen weiter und scheitern erst im Test an einer fehlenden Datei. Beides ist lehrreich. Wichtig ist die Reihenfolge — erst die Meldung lesen und benennen, dann korrigieren. Wer schnell fertig ist, ergänzt einen zweiten Job für das Linting; dann sehen Sie gleich, dass Jobs tatsächlich nebeneinander laufen.

8:37 Die fünf Schritte folgen dem natürlichen Aufbau: erst der Auslöser, dann die Vorbereitung der Umgebung, dann die eigentliche Arbeit. Achten Sie im dritten Schritt auf sprechende Namen — das kostet zehn Sekunden und spart später Minuten. Schritt vier ist der eigentliche Lerninhalt: den Fehler herbeiführen und die Meldung tatsächlich lesen, statt sofort zu reparieren.

8:58 Und Schritt fünf zeigt Ihnen den erneuten Start in seiner sinnvollen Verwendung — nach einer Korrektur, mit einer Erwartung, was jetzt passieren sollte. Der erste Punkt kostet die meiste Verwirrung: Sie legen den Workflow auf einem Branch an, für den der Auslöser nicht greift, und warten dann auf einen Lauf, der nie kommt.

9:16 Der zweite macht die ganze Übung wertlos — wenn alle Kommandos in einem Schritt stehen, sagt Ihnen das Log nicht, welches davon gescheitert ist. Der dritte erzeugt Fehler, die lokal nicht auftreten. Und der vierte ist der eigentliche Punkt dieser Übung: Wer sofort repariert, ohne die Meldung gelesen zu haben, übt genau die Fähigkeit nicht, um die es hier geht.

9:36 Im nächsten Modul schneiden wir dann die Auslöser richtig zu.