Skip to main content

Grundlegendes zu GitHub Actions

Hier erfährst du mehr über die Grundlagen von GitHub Actions, einschließlich der Kernkonzepte und wesentlichen Terminologie.

Note

Auf GitHub gehostete Runner werden aktuell nicht auf GitHub Enterprise Server unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Übersicht

GitHub Actions ist eine Plattform für Continuous Integration und Continuous Delivery (CI/CD), mit der du deine Build-, Test- und Bereitstellungspipeline automatisieren kannst. Du kannst Workflows erstellen, mit denen du alle Pull Requests für dein Repository erstellen und testen sowie gemergte Pull Requests für die Produktion bereitstellen kannst.

GitHub Actions ist nicht auf DevOps beschränkt und kann auch für andere Ereignisse in deinem Repository Workflows ausführen. So kannst du z. B. einen Workflow für das automatische Hinzufügen geeigneter Bezeichnungen ausführen, sobald in deinem Repository ein neues Issue erstellt wird.

Zum Ausführen von Workflows für Ihre GitHub Enterprise Server-Instance musst du eigene virtuelle Linux-, Windows- oder macOS-Computer hosten. Selbstgehostete Runner können physisch, virtuell, in einem Container, lokal oder in einer Cloud sein.

Weitere Informationen zur Integration von GitHub Actions in dein Unternehmen findest du unter Einführen von GitHub Actions in deinem Unternehmen.

Die Komponenten von GitHub Actions

Du kannst konfigurieren, dass bei einem Ereignis in deinem Repository ein GitHub Actions-Workflow ausgelöst wird. Dabei kann es sich etwa um das Öffnen eines Pull Requests oder das Erstellen eines Issues handeln. Der Workflow enthält einen oder mehrere Aufträge, die nacheinander oder gleichzeitig ausgeführt werden können. Jeder Auftrag wird innerhalb eines eigenen Runners der VM oder in einem Container ausgeführt und verfügt über einen oder mehrere Schritte. Diese führen entweder ein von Ihnen definiertes Skript oder eine Aktion aus. Dabei handelt es sich um eine wiederverwendbare Erweiterung zur Vereinfachung des Workflows.

Diagramm eines Ereignisses, das Runner 1 veranlasst, Auftrag 1 auszuführen, was wiederum Runner 2 veranlasst, Auftrag 2 auszuführen. Jeder der Aufträge ist in mehrere Schritte unterteilt.

Workflows

Ein Workflow ist ein konfigurierbarer automatisierter Prozess zur Ausführung eines oder mehrerer Aufträge. Workflows werden durch eine im Repository eingecheckte YAML-Datei definiert. Die Auslösung ihrer Ausführung erfolgt durch ein Ereignis in deinem Repository, manuell oder nach einem definierten Zeitplan.

Workflows werden im .github/workflows-Verzeichnis in einem Repository definiert. Ein Repository kann mehrere Workflows enthalten, die jeweils unterschiedliche Aufgaben ausführen können, wie:

  • Erstellen und Testen von Pull Requests.
  • Bereitstellen Ihrer Anwendung bei jeder Erstellung eines Release.
  • Hinzufügen einer Bezeichnung, wenn ein neues Issue geöffnet wird.

Du kannst innerhalb eines anderen Workflows auf einen Workflow verweisen. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Weitere Informationen findest du unter Schreiben von Workflows.

Events

Bei einem Ereignis handelt es sich um eine bestimmte Aktivität in einem Repository, die die Ausführung eines Workflows auslöst. Eine Aktivität kann beispielsweise von GitHub stammen, wenn ein Pull Request erstellt, ein Issue geöffnet oder ein Commit per Push in ein Repository übertragen wird. Die Ausführung eines Workflows kann auch nach einem Zeitplan, durch Posten in einer REST-API oder manuell ausgelöst werden.

Eine vollständige Liste der Ereignisse zum Auslösen von Workflows findest du unter Ereignisse, die Workflows auslösen.

Aufträge

Ein Auftrag umfasst mehrere Schritte in einem Workflow, die in demselben Runner ausgeführt werden. Jeder Schritt besteht entweder aus einem Shellskript oder aus einer Aktion, die ausgeführt werden. Die Schritte werden nacheinander ausgeführt und sind voneinander abhängig. Da alle Schritte im gleichen Runner ausgeführt werden, kannst du Daten eines Schritts für andere Schritte freigeben. So kann z. B. in einem Schritt eine Anwendung erstellt und im nächsten Schritt die erstellte Anwendung getestet werden.

Ein Auftrag so konfiguriert werden, dass er Abhängigkeiten zu anderen Aufträgen enthält. Standardmäßig verfügen Aufträge nicht über Abhängigkeiten und werden parallel ausgeführt. Wenn ein Auftrag von einem anderen Auftrag abhängt, wartet er auf den Abschluss des abhängigen Auftrags, bevor er ausgeführt wird.

Sie könnten zum Beispiel mehrere Build-Aufträge für verschiedene Architekturen ohne Auftragsabhängigkeiten konfigurieren und einen Auftrag zur Paketerstellung, der von diesen Aufträgen abhängig ist. Dadurch werden die Buildaufträge parallel ausgeführt, und der Auftrag zur Paketerstellung wird ausgeführt, wenn sie erfolgreich abgeschlossen sind.

Weitere Informationen findest du unter Auswählen, was in dem Workflow passiert.

Aktionen

Bei einer Aktion handelt es sich um eine benutzerdefinierte Anwendung für die GitHub Actions-Plattform zur Ausführung einer komplexen und häufig ausgeführten Aufgabe. Mit einer Aktion können Sie die Menge des Codes in Ihren Workflow-Dateien reduzieren. Mit einer Aktion können Sie Ihr Git-Repository aus GitHub abrufen, die korrekte Toolkette für Ihre Buildumgebung einrichten oder die Authentifizierung bei Ihrem Cloudanbieter einrichten.

Du kannst eigene Aktionen schreiben oder im GitHub Marketplace nach Aktionen für deine Workflows suchen.

Um Aktionen für dein gesamtes Unternehmen freizugeben, ohne diese für den öffentlichen Zugriff zu veröffentlichen, kannst du die Aktionen in einem internen Repository speichern und dieses dann so konfigurieren, dass der Zugriff auf GitHub Actions-Workflows in anderen Repositorys im Besitz derselben Organisation oder einer anderen Organisation im Unternehmen zugelassen ist. Weitere Informationen finden Sie unter Freigeben von Aktionen und Workflows in deinem Unternehmen.

Weitere Informationen zu Aktionen sind unter „Freigeben von Automatisierungen“ zu finden.

Runner

Ein Runner ist ein Server, auf dem die Workflows ausgeführt werden, wenn sie ausgelöst werden. Jeder Runner kann jeweils nur einen Auftrag ausführen. Für GitHub Enterprise Server musst du eigene Runner hosten.

Weitere Informationen sind unter „Deinen eigenen Runner hosten“ zu finden.

Nächste Schritte

GitHub Actions kann dir dabei helfen, nahezu alle Aspekte deines Anwendungsentwicklungsprozesses zu automatisieren. Willst du loslegen? Hier findest du einige hilfreiche Ressourcen für deine nächsten Schritte mit GitHub Actions:

  • Informationen zum Erstellen eines GitHub Actions-Workflows sind unter „Verwenden von Workflowvorlagen“ zu finden.
  • Informationen zu CI-Workflows (Continuous Integration) sind unter „Erstellen und Testen“ zu finden.
  • Informationen zum Erstellen und Veröffentlichen von Paketen findest du unter Veröffentlichen von Paketen.
  • Informationen zum Bereitstellen von Projekten findest du unter Anwendungsfälle und Beispiele.
  • Informationen zum Automatisieren von Aufgaben und Prozessen auf GitHub findest du unter Projekte verwalten.
  • Beispiele, die komplexere Features von GitHub Actions veranschaulichen, sind unter „Anwendungsfälle und Beispiele“ zu finden. Diese detaillierten Beispiele erläutern, wie man Code auf einem Runner testen, auf die GitHub-CLI zugreifen und erweiterte Funktionen wie Parallelität und Testmatrizen verwenden kann.

Weitere Informationen