Bevor wir uns in die praktische Arbeit mit GitHub Actions stürzen, lohnt sich ein Blick auf das konzeptionelle Fundament. Wer die Grundbegriffe und ihre Beziehungen zueinander versteht, kann Workflows nicht nur erstellen, sondern auch gezielt optimieren und Probleme eigenständig lösen.
Die Architektur von GitHub Actions basiert auf einer Handvoll zentraler Konzepte, die ineinandergreifen. Keine dieser Komponenten existiert isoliert – erst ihr Zusammenspiel macht das System funktionsfähig. Die folgende Übersicht zeigt diese Beziehungen:
Ein Workflow definiert einen automatisierten Ablauf von Anfang bis
Ende. Technisch gesehen handelt es sich um eine YAML-Datei, die im
Verzeichnis .github/workflows des Repositories liegt.
Konzeptionell ist ein Workflow jedoch mehr: Er beschreibt wann
etwas passieren soll, was passieren soll und wie die
einzelnen Teile zusammenhängen.
Ein typisches Repository enthält mehrere Workflows mit unterschiedlichen Zwecken. Ein Workflow kümmert sich um Continuous Integration und läuft bei jedem Push. Ein anderer handhabt das Deployment nach erfolgreichem Merge in den Main-Branch. Ein dritter verwaltet vielleicht automatisch Issue-Labels oder erstellt Release-Notes.
Diese Trennung ist bewusst gewählt. Statt einen monolithischen Workflow zu bauen, der alles kann, entstehen spezialisierte, wartbare Einheiten. Jeder Workflow hat eine klare Verantwortlichkeit und lässt sich unabhängig von anderen bearbeiten und testen.
Praktischer Hinweis: Die Benennung der
Workflow-Dateien ist frei wählbar, sollte aber den Zweck widerspiegeln.
Namen wie ci.yml, deploy-production.yml oder
pr-labeler.yml machen auf den ersten Blick klar, worum es
geht.
Workflows sind reaktiv. Sie warten auf Events – Ereignisse die signalisieren, dass etwas passiert ist, worauf der Workflow reagieren soll. GitHub kennt über 40 verschiedene Event-Typen, die sich in drei Kategorien einteilen lassen:
| Event-Kategorie | Beispiele | Typische Anwendung |
|---|---|---|
| Repository-Events | push, pull_request, issue,
release |
CI/CD, Automatisierung von Entwicklungsprozessen |
| Zeitgesteuerte Events | schedule (Cron-Syntax) |
Nächtliche Builds, regelmäßige Wartungsaufgaben |
| Manuelle Events | workflow_dispatch,
repository_dispatch |
On-Demand-Deployments, externe Trigger |
Die Wahl des richtigen Events bestimmt, wann der Workflow aktiv wird.
Ein push-Event feuert bei jedem Commit, der ins Repository
gelangt. Das pull_request-Event reagiert auf Änderungen an
Pull Requests – aber Vorsicht: Es gibt Untertypen wie
opened, synchronize oder closed,
die jeweils unterschiedliche Zeitpunkte im Lebenszyklus eines Pull
Requests abbilden.
Events können mit Filtern kombiniert werden. Ein Workflow läuft vielleicht nur bei Pushes auf den Main-Branch, oder nur wenn bestimmte Dateipfade betroffen sind. Diese Flexibilität verhindert unnötige Workflow-Läufe und spart Ressourcen.
Ein Workflow besteht aus einem oder mehreren Jobs. Jeder Job repräsentiert eine zusammenhängende Aufgabe – etwa “Code kompilieren”, “Tests ausführen” oder “Docker-Image bauen”. Die Granularität liegt im Ermessen des Workflow-Autors, folgt aber meist einer natürlichen Aufteilung der Arbeit.
Jobs haben eine wichtige Eigenschaft: Sie laufen standardmäßig parallel. Gibt es drei Jobs ohne explizite Abhängigkeiten, startet GitHub Actions alle drei gleichzeitig. Das beschleunigt die Ausführung erheblich, erfordert aber Aufmerksamkeit bei der Modellierung. Ein Job, der auf Artefakte eines anderen Jobs angewiesen ist, muss diese Abhängigkeit explizit deklarieren.
Die Definition von Abhängigkeiten erfolgt über das
needs-Schlüsselwort. Ein Deployment-Job könnte etwa
angeben: needs: [build, test]. Damit wartet er, bis beide
vorherigen Jobs erfolgreich abgeschlossen sind. Schlägt einer der
benötigten Jobs fehl, wird der abhängige Job gar nicht erst
gestartet.
Analogie: Jobs verhalten sich wie Aufgaben in einem Projektplan. Manche können parallel erledigt werden (zwei Entwickler implementieren unterschiedliche Features), andere müssen sequenziell ablaufen (erst entwickeln, dann testen, dann deployen).
Innerhalb eines Jobs befinden sich Steps – die einzelnen Arbeitsschritte, die nacheinander ausgeführt werden. Ein Step macht genau eine Sache: Ein Shell-Kommando ausführen, eine Action aufrufen, eine Variable setzen. Diese Feinkörnigkeit macht Workflows lesbar und nachvollziehbar.
Steps teilen sich eine Ausführungsumgebung. Dateien, die in einem Step erstellt werden, sind in nachfolgenden Steps verfügbar. Environment-Variablen können von einem Step zum nächsten weitergereicht werden. Diese Kontextfreigabe innerhalb eines Jobs steht im Gegensatz zur Isolation zwischen Jobs – dort müssen Daten explizit über Artefakte ausgetauscht werden.
Ein typischer Job für eine Node.js-Anwendung könnte so strukturiert sein:
npm ci)npm test)npm run build)Jeder dieser Schritte ist ein eigenständiger Step. Die Sequenz ergibt sich aus der Reihenfolge in der YAML-Datei.
Actions sind das Werkzeug, das GitHub Actions von vielen anderen CI/CD-Systemen unterscheidet. Statt komplexe Shell-Scripts zu schreiben, können Steps vorgefertigte Actions aufrufen. Eine Action kapselt eine bestimmte Funktionalität – etwa “Repository klonen”, “Umgebung einrichten” oder “zu AWS deployen”.
Der GitHub Marketplace listet Tausende öffentlicher Actions. Die
meisten davon sind Open Source und werden von der Community gepflegt.
Besonders die offiziellen Actions von GitHub selbst (erkennbar am
actions/-Präfix) sind gut dokumentiert und zuverlässig
maintained.
Drei grundlegende Action-Typen existieren:
JavaScript-Actions laufen direkt auf dem Runner und sind besonders schnell. Sie eignen sich für Operationen, die keine speziellen Systemabhängigkeiten haben.
Docker-Container-Actions kapseln ihre gesamte Umgebung. Das macht sie portabel, aber auch langsamer, da der Container bei jeder Ausführung gebaut oder gepullt werden muss.
Composite-Actions kombinieren mehrere Steps zu einer wiederverwendbaren Einheit. Sie dienen primär der Code-Organisation und lassen sich als Makros verstehen.
| Action-Typ | Geschwindigkeit | Portabilität | Anwendungsfall |
|---|---|---|---|
| JavaScript | Sehr schnell | Hoch | API-Calls, Datentransformation, GitHub-Interaktion |
| Docker | Langsam | Sehr hoch | Komplexe Abhängigkeiten, spezielle Tools |
| Composite | Schnell | Mittel | Wiederverwendung von Workflow-Logik |
Die Verwendung einer Action ist denkbar einfach. Statt ein mehrzeiliges Script zu schreiben, referenziert ein Step die Action mit ihrem Namen und optional Parametern. Die Wartung der eigentlichen Logik übernimmt der Action-Maintainer.
Runner sind die physischen oder virtuellen Maschinen, auf denen Workflows tatsächlich ausgeführt werden. GitHub stellt drei Standard-Betriebssysteme bereit: Ubuntu Linux (der Default), Windows und macOS. Jeder Workflow-Lauf bekommt eine frische VM, die nach Abschluss wieder verworfen wird.
Diese Einweg-Natur hat Konsequenzen. Zwischen zwei Läufen desselben Workflows gibt es keine Persistenz – keine installierten Tools, keine gecachten Dependencies, keine Zustandsinformationen. Jeder Lauf startet bei null. Das garantiert Reproduzierbarkeit, erfordert aber auch Strategien für häufig benötigte Daten. Cache-Mechanismen und Artefakte helfen hier weiter.
GitHub-hosted Runner decken viele Standardszenarien ab. Sie kommen mit einer umfangreichen Tool-Vorinstallation: gängige Programmiersprachen, Build-Tools, Docker, CLI-Tools für Cloud-Provider. Die genaue Liste variiert je nach Betriebssystem und ändert sich mit Updates.
Für spezielle Anforderungen – sei es exotische Hardware, besondere Sicherheitsanforderungen oder einfach mehr Performance – können selbstgehostete Runner eingesetzt werden. Diese laufen auf eigener Infrastruktur und geben volle Kontrolle über die Umgebung. Der Preis dafür: Wartungsaufwand und Verantwortung für Sicherheit und Verfügbarkeit.
Die einzelnen Konzepte ergeben erst im Zusammenhang Sinn. Ein Event triggert einen Workflow. Der Workflow definiert Jobs, die auf Runnern ausgeführt werden. Jeder Job besteht aus Steps, die entweder Scripts ausführen oder Actions aufrufen. Zwischen Jobs können Abhängigkeiten bestehen, innerhalb von Jobs teilen Steps ihre Umgebung.
Diese Hierarchie – Event → Workflow → Job → Step → Action – bildet das mentale Modell, mit dem wir über GitHub Actions denken sollten. Wer diese Struktur verinnerlicht, kann Workflows nicht nur lesen und verstehen, sondern auch effektiv strukturieren und debuggen.
Ein weiterer Aspekt verdient Beachtung: Die Granularität der Konzepte spiegelt unterschiedliche Abstraktionsebenen wider. Events und Workflows operieren auf Repository-Ebene. Jobs repräsentieren fachliche Aufgaben. Steps sind technische Implementierungsdetails. Actions abstrahieren wiederverwendbare Funktionalität. Diese Schichtung ermöglicht es, auf der jeweils passenden Ebene zu arbeiten – mal strategisch beim Workflow-Design, mal taktisch bei der Step-Implementierung.