GitHub Actions - Vorstellung und erster Einstieg

4. März 2020 in Builds & Tests Open Source, GitHub, Workflows

Mit GitHub Actions ist es möglich, beliebige Workflows in einem GitHub Repository zu definieren und dort auch automatisch ausführen zu lassen. Das können Builds und Tests zur kontinuierlichen Integration sein, aber auch völlig unabhängige Prozesse, zum Beispiel zur regelmäßigen Prüfung bestimmter Anforderungen.

In den letzten Wochen und Monaten haben wir mehrere Dutzend Workflows mit GitHub Actions abgebildet und entsprechende Erfahrungen gesammelt. Im Rahmen einer kleinen Artikelserie werden wir einige der vielfältigen Möglichkeiten vorstellen, die sich mit GitHub Actions auftun.

Einige Stärken von GitHub Actions

Nahtlose Integration mit GitHub: Da GitHub Actions direkt im Repository auf GitHub ausgeführt wird, liegt die Prozessausführung direkt beim Code, was die Wege verkürzt.
Weniger bis keine separaten Werkzeuge mehr nötig: Das kann so weit gehen, dass komplette Build-Server abgelöst werden können. So sind bei uns zwei (voneinander unabhängige) Jenkins-Instanzen überflüssig geworden.
(Wieder)verwendung der Repository-Secrets: Zugangsdaten und andere Secrets können direkt beim Repository hinterlegt werden (in Jenkins war das hingegen zentral).
Zahlreiche Events: Workflows können durch sehr viele mögliche Ereignisse ausgelöst werden. Hierzu zählen nicht nur zeitgesteuerte Trigger, Pushes und Pull Requests, sondern auch Aktivitäten rund um Tickets, Wikiseiten, Forks, Deployments oder auch Webhooks.
Container überall: Die einzelnen Aktionen, welche in Workflows verwendet werden können, lassen sich sowohl in TypeScript als auch mit Docker beschreiben. Workflows werden durch das Zusammenspiel unterschiedlicher Docker-Container ausgeführt. Auch etwaige von den Workflows verwendete Drittdienste wie etwa Datenbanken werden in Form von Docker-Services betrieben.

Aktuell noch vorhandene Schwächen von GitHub Actions

Keine Wiederverwendung von Workflows: Es ist gegenwärtig nicht möglich, Workflows in mehreren Repositories zu verwenden. Das ist insbesondere unglücklich, wenn ein und derselbe Workflow für mehrere gleichartige Komponenten benötigt wird. In Jenkins konnten wir (wie hier beschrieben) Groovy-Skripte auslagern und dynamisch aus einem beliebigen Git-Repository dazu laden.; Zu diesem Problem existieren mehrere Diskussionen, aber leider noch keine Lösung.
Testergebnisse und Metriken: Wo Jenkins sehr stark ist, fällt GitHub Actions leider deutlich ab: sowohl die Erhebung als auch die Visualisierung von Testergebnissen, Analyseergebnissen und Code-Metriken ist (derzeit noch) quasi nicht vorhanden. Von einem Vergleich mehrerer Builds und der daraus resultierenden Veränderungen ganz zu schweigen.; Auch hierzu gibt es eine ganze Reihe an Diskussionen.
Alte Artefakte löschen: Offenbar scheinen Artefakte aktuell noch ewig aufgehoben zu werden (Thread). Das wird dann zum Problem, wenn der verfügbare Speicherplatz (GitHub Storage) ausgeschöpft ist.; Hierfür gibt es verschiedene Workarounds: so lassen sich Dateien zum Beispiel zu Releases hinzufügen oder auch auf andere Server kopieren. Es müssen also nicht unbedingt Artefakte verwendet werden, wobei diese den praktischen Vorteil haben, dass sie direkt bei dem entsprechenden Build referenziert werden.
Parallele Ausführungen begrenzen: Die Anzahl paralleler Ausführungen desselben Workflows lässt sich nicht steuern. Pusht man also dreimal schnell hintereinander Änderungen in ein Repository, läuft der entsprechende Build auch in drei Instanzen gleichzeitig.; Die dazugehörige Diskussion liefert auch mögliche Workarounds. In den meisten Fällen ist dieses Problem aber nicht kritisch.
Verfügbare Actions: Die Liste der Aktionen ist auf den ersten Blick zwar relativ groß. Bei näherer Betrachtung stellt sich aber heraus, dass manche Bereiche direkt von 50 Plug-ins abgedeckt, andere jedoch noch so gut wie gar nicht unterstützt werden. Je nach Anforderungen wird man hier sehr schnell glücklich oder muß ggf. auch selbst Hand anlegen. Wobei sich das Ökosystem hier permanent entwickelt.

Wie loslegen?

Die folgenden Ressourcen helfen beim Einstieg und zeigen Beispiele dafür, wie die Workflows im YAML-Format beschrieben werden:

Es lohnt sich, hier etwas Zeit zu investieren. Die Dokumentation ist insgesamt nicht unbedingt intuitiv, aber GitHub arbeitet aktiv daran, die Struktur sukzessive zu verbessern.

In den nächsten Artikeln werden wir auf einige konkrete Anwendungsfälle eingehen, die aktuell so nicht in der offiziellen Doku zu finden sind.