Grundlagen von GitHub Actions – Hands-on Tutorial

In diesem Blog-Artikel möchte ich euch vorstellen, wie man GitHub Actions einsetzt, damit ihr langweilige repetitive Aufgaben automatisieren und mehr Zeit mit dem Coden verbringen könnt.

Falls eure Code Base bereits auf GitHub ist, könnt ihr direkt starten und zukünftig den kompletten Workflow an einem einzigen Ort verwalten. Keine langwierigen Konfigurationen mehr, die über verschiedene Plattformen und Dienste verteilt sind.

Wie funktioniert GitHub Actions?

Betrachten wir ein GitHub Repo, können verschiedene Events auftreten. Zum Beispiel kann jemand eine Pull-Request erstellen, gibt dem Repo einen Stern oder eine Issue wird erstellt.

Diese Events – ein komplette Liste findet ihr hier – können einen oder mehrere Workflows anstoßen. Workflows laufen auf virtuellen Maschinen in der Cloud und werden von GitHub zur Verfügung gestellt. Ihr legt fest, welche Schritte diese Maschinen ausführen, damit eure Aufgaben automatisiert ablaufen.

Häufig werden mit GitHub-Actions Test-Suiten durchlaufen, Docker Images erstellt und in eine Registry gepusht oder Release-fähige Versionen durch einen Security Scan auf Schwachstellen überprüft.

Um Kosten braucht ihr euch dabei keine Sorgen zu machen, da GitHub ein sehr großzügiges Free-Tier hat. Öffentliche Repositories sind sogar komplett kostenfrei.

Hands-on: Wir bauen einen Workflow!

Schauen wir uns einen Workflow und seine Erstellung einmal genauer an.

Um einen Workflow für GitHub sichtbar zu machen, muss in eurem Repo ein Ordner mit dem Namen .github  angelegt sein, in dem sich wiederum ein Ordner mit dem Namen workflows  befinden muss. Genau in diesem Ordner könnt ihr nun eure Workflows anlegen.

Alle Workflows werden in YAML-Dateien gespeichert. Erstellen wir also eine integration.yml -Datei, um loszulegen.

Ein guter Startpunkt für das Arbeiten mit GitHub Actions ist es, eine simple CI-Pipeline zu implementieren. Unsere App könnte in diesem Fall eine Node.js-Anwendung sein, die eine HTML-Seite hostet, etwas Javascript beinhaltet und mit Webpack gebaut wird.

Zusätzlich testen wir mit dem Test-Framework Jest, ob unser Code richtig funktioniert. Der Workflow soll ausgeführt werden, wenn jemand einen Pull Request auf den Main Branch anstößt.

Bisher muss jeder Developer, bevor er einen Pull Request für seinen Branch erstellt, selbstständig auf seinem Rechner die Node Modules installieren, die Tests ausführen und das Build Script ausführen.

Diese immer wiederkehrenden Schritte werden nun automatisiert und dienen als Anreiz, kleinere Teile an Code iterativ zu pushen.

Wir geben unserem Workflow den Namen Node continuous integration . Im Anschluss legen wir fest, für welche Events dieser Workflow ausgeführt wird. Jeder Workflow hat mindestens einen Job. Alle Jobs werden unter dem jobs -Objekt gebündelt.

Wir nennen ihn test_pull_request . Der Befehl runs-on  bestimmt das Betriebssystem der VM. Im Anschluss werden alle Schritte (steps) durchlaufen, die der Developer sonst manuell ausführt.

Hinweis:
Jeder Job läuft auf einer eigenen VM-Instanz. Man greift also bei verschiedenen Jobs nicht auf einen Shared-Folder zu. Steps werden pro Job sequentiell bearbeitet, wohingegen Jobs voreingestellt parallel laufen.

Vielleicht fragt ihr euch bereits, was z. B. hinter dem Befehl - uses: actions/checkout@v2  steckt und wieso genau diese Syntax benötigt wird. Das erkläre ich euch im Abschnitt Marketplace.

Der Marketplace

Grundsätzlich ist es möglich – wie auch in späteren Steps gezeigt – command-line Befehle direkt auszuführen. Da das Aufsetzen von Node-Umgebungen oder das Importieren von Quellcode häufig vorkommt, gibt es bereits vorkonfigurierte Blöcke.
Diese fassen alle für den Zweck erforderlichen Aufgaben zusammen. Es lohnt sich also immer, zuerst in den extra dafür vorgesehenen Marketplace zu schauen. Eventuell findet man bereits eine action und erspart sich so einen Nachmittag voller Fragezeichen und Kopfzerbrechen.

Hier gibt es nicht nur offizielle von GitHub erstellte, sondern auch von der Community für jeden verwendbare actions …

Bevor wir aber den Faden verlieren, schnell zurück zu unserem Workflow.
Hinter der action/checkout@v2  versteckt sich eine von GitHub erstellte Möglichkeit, sein aktuelles Repo (mit aktuellem Commit) komplett auf die derzeitige VM zu kopieren. „@v2“ steht hierbei für die Version.
Der nächste step setzt uns eine Node-Umgebung der Version 16 auf. Im Anschluss werden die Dependencies installiert, der Code getestet und das Build-Script ausgeführt.

Aber wo finde ich meine Actions, Workflows und Ergebnisse? In der Hauptleiste deines Repos!

Nachdem ihr auf den Actions-Tab geklickt habt, öffnet sich eine Übersicht aller Workflows. Auf der linken Seite sind alle im Repo vorhandenen Workflows aufgelistet. Mittig sind derzeit oder bereits gelaufene Workflows zu finden (Workflow-Log).

Waren keine Fehler vorhanden, seht ihr einen grünen Haken, andersherum ein rotes X.

Das hört sich alles abstrakt an und man weiß doch gar nicht, woran es genau lag, sollte ein Fehler auftreten?!

Kein Problem, klickt einfach auf einen Workflow aus dem Workflow-Log und ihr bekommt eine Übersicht des Ablaufes. Es wird genau aufgelistet, welche Schritte die VM durchgeführt hat und ihr seht, an welchen Schritten es Probleme gab.

Im Anschluss behebt man die aufgetretenen Fehler, erstellt einen neuen Commit und der Workflow wird erneut gestartet. Hat jetzt alles funktioniert, seht ihr sowohl unter Workflows einen grünen Haken als auch in eurem Pull-Request.

Dein Start

Du hast gerade kein Projekt, an dem du GitHub-Actions ausprobieren kannst?
Kein Problem, erstelle einfach einen Fork unseres Beispiel-Projektes teste alles und erweitere es mit deinen eigenen Ideen!