GitHub Actions - Vorstellung und erster Einstieg

in  Builds & Tests , ,

GitHub Actions - Vorstellung und erster Einstieg

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.

Weitere Beiträge in Kategorie Builds & Tests

GitHub integriert Code Security Scanner
- Im offiziellen GitHub Changelog werden regelmäßig Beiträge über unterschiedliche Neuerungen und Innovationen auf der GitHub Plattform veröffentlicht, zum Beispiel in Bezug auf Funktionen in der …
GitHub Actions - Eine Aktion zum Bauen und Testen von Zikula-Modulen
- Vor ein paar Wochen haben wir unsere generator-action vorgestellt, welche die einfache Generierung von Zikula-Erweiterungen mit dem Standalone Generator von ModuleStudio erlaubt. Diese Action wird als …
GitHub Actions - Eine Aktion zum Generieren von Zikula-Modulen
- Der Standalone-Generator ModuleStudio bietet einen Standalone-Generator, mit dem sich jederzeit eine Anwendung über die Kommandozeile generieren lässt. Einige allgemeine Informationen hierzu sind der …
GitHub Actions - Programmatische Trigger, Build Pipelines, Dashboard
- In diesem Beitrag geht es darum, mehrere und unterschiedliche Build Jobs miteinander zu verknüpfen. Je größer eine Build Infrastruktur wird, desto häufiger wird man mit solchen Anforderungen …
GitHub Actions - Java-Projekte bauen und testen
- Nachdem im letzten Artikel gezeigt wurde, mit welchen Mitteln sich in GitHub Actions Projekte auf Basis von PHP verarbeiten lassen, schauen wir nun auch einmal kurz in die Java-Welt. Werkzeuge für das …