Zum Inhalt springen

GitHub Actions

Männliche Person, frontal, schaut in die Kamera; trägt kariertes Hemd über dunkelfarbigem T‑Shirt; heller Innenraum mit unscharfem Monitor oder Poster links und Fenster rechts.

von Richard Albrecht am 03.11.2026

GitHub Actions ist der in GitHub eingebaute Dienst, der Abläufe bei Ereignissen im Repository startet. Ein Push, ein Pull Request oder ein Zeitplan löst einen Workflow aus, der auf einer Maschine von GitHub läuft.

GitHub Actions

Der in GitHub eingebaute Dienst, der Abläufe bei Ereignissen im Repository startet.
Beispiel: „GitHub Actions ließ bei jedem Pull Request die Tests gegen zwei PHP-Fassungen laufen.“

Die Abläufe stehen als YAML-Dateien im Verzeichnis .github/workflows des Projekts. Ausgelöst werden sie unter anderem von push, pull_request, schedule und einem Knopf in der Oberfläche.

Abgrenzung zu GitLab CI und Jenkins: Dieselbe Aufgabe, andere Anbieter. Der Unterschied liegt darin, dass Actions im Repository eingebaut ist und keinen eigenen Dienst braucht.

Wie ein Workflow in GitHub Actions aufgebaut ist

In drei Ebenen. Der Workflow nennt den Auslöser, darin stehen Jobs mit je einer Laufzeitumgebung, und ein Job besteht aus Schritten: eigene Befehle oder fertige Bausteine, die jemand anderes veröffentlicht hat.

Jobs laufen standardmäßig gleichzeitig und können aufeinander warten. Damit lässt sich derselbe Ablauf bauen, den eine Pipeline mit Stufen beschreibt, siehe Pipeline-Stage.

Was GitHub Actions kostet

In öffentlichen Repositories nichts. In privaten rechnet GitHub die Laufzeit in Minuten ab, mit einem Freibetrag je Tarif; Läufe auf Windows und macOS zählen mehrfach gegenüber Linux.

Wer viel prüft, läuft deshalb in die Kostenfrage. Zwei Wege helfen: Zwischenspeicher für Abhängigkeiten, damit ein Lauf kürzer wird, und eigene Maschinen als Läufer, wenn die Minuten teurer werden als die Hardware.

Worauf bei fremden Actions zu achten ist

Auf die Rechte und auf die Fassung. Ein fremder Baustein läuft im Lauf mit, sieht die Geheimnisse des Repositories und kann sie weitergeben; ein Verweis auf eine Marke wie v4 zeigt morgen auf anderen Code als heute.

Deshalb gehört ein Baustein aus fremder Hand auf einen festen Commit festgelegt, und die Geheimnisse bekommen nur die Jobs, die sie brauchen, siehe Secrets-Verwaltung.

Siehe auch:

Build-Pipeline

Der eingerichtete Ablauf, der aus einem Stand im Repository ein ausgeliefertes Ergebnis macht.

#Programmiersprachen

Continuous Integration (CI)

Die Praxis, Änderungen mehrmals täglich zusammenzuführen und dabei prüfen zu lassen.

#Deployment & Versionierung

Pipeline-Stage

Ein Abschnitt in einer Pipeline, der erst beginnt, wenn der vorige bestanden ist.

#Deployment & Versionierung

Repository

Der Ort, an dem ein Projekt samt seiner gesamten Geschichte liegt.

#Deployment & Versionierung

Secrets-Verwaltung

Das geordnete Aufbewahren von Zugangsdaten, Schlüsseln und Token.

#Deployment & Versionierung

Pull Request

Die Bitte, einen Branch in den gemeinsamen Stand zu übernehmen, samt Ort für die Durchsicht.

#Deployment & Versionierung