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 Actions - PHP-Projekte bauen und testen
- Eine Aktion zur PHP-Einrichtung Für die wichtigsten Punkte, die notwendig sind, um ein auf PHP basierendes Projekt zu testen, gibt es die Action setup-php. Diese bietet unter anderem folgende …
GitHub Actions - Abhängigkeiten automatisch aktualisieren
- Nach der allgemeinen Einführung in GitHub Actions kommen wir nun zu dem ersten Anwendungsfall, der in vielen Projekten angewendet werden kann. Fast jedes Softwareprojekt bedient sich heutzutage …
Automatisierte Tests - ein Zwischenstand
- Seit dem kürzlich angekündigten Start der Testautomatisierung von ModuleStudio ist bereits eine Menge geschehen. So gibt es knapp 1.000 Tests für die DSL, darunter vorwiegend für UI-unabhängige …
Ran an die Tests!
- Schon ewig geplant, aber lange schmählich vernachlässigt, habe ich bei ModuleStudio die automatisierten Tests. Zwar ist schon seit Längerem die Infrastruktur dahingehend ausgerichtet, was …
Erneuertes Build-System für ModuleStudio
- Die Komponenten von ModuleStudio werden nun mit anderen Technologien gebaut. Statt Buckminster wird jetzt das Maven-basierte Tycho eingesetzt. Die Jenkins-Jobs wurden auf Pipelines umgestellt und …