Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.
GitHub AE ist derzeit begrenzt freigegeben.

Grundlegendes zu GitHub Actions

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

Ü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 dein Unternehmen 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 Verzeichnis .github/workflows in einem Repository definiert, und ein Repository kann mehrere Workflows aufweisen, die jeweils eine andere Gruppe von Aufgaben ausführen können. So kannst du etwa einen Workflow zum Erstellen und Testen von Pull Requests erstellen, einen zweiten zum Bereitstellen deiner Anwendung bei jeder neuen Erstellung eines Releases und einen dritten zum Hinzufügen von Bezeichnungen bei jeder Öffnung eines weiteren Issues.

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

Weitere Informationen zu Workflows findest du unter Verwenden von Workflows.

Ereignisse

Bei einem Ereignis handelt es sich um eine bestimmte Aktivität in einem Repository, die die Ausführung eines Workflows auslöst. Die 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.

Du kannst einen Auftrag so konfigurieren, dass er Abhängigkeiten zu anderen Aufträgen enthält. Standardmäßig verfügen Aufträge nicht über Abhängigkeiten und werden gleichzeitig ausgeführt. Verfügt ein Auftrag über eine Abhängigkeit zu einem anderen Auftrag, wird er erst nach dessen Abschluss ausgeführt. Du kannst z. B. mehrere Buildaufträge für unterschiedliche Architekturen ohne Abhängigkeiten erstellen und anschließend einen Auftrag zur Paketerstellung, der von diesen abhängig ist. Dadurch werden die Buildaufträge gleichzeitig ausgeführt, und der Auftrag zur Paketerstellung wird erst ausgeführt, nachdem diese erfolgreich abgeschlossen wurden.

Weitere Informationen zu Aufträgen findest du unter Verwenden von Aufträgen.

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 kannst du die Menge des Codes in deinen Workflowdateien reduzieren. Mit einer Aktion kannst du dein Git-Repository aus GitHub abrufen, die korrekte Toolkette für deine Buildumgebung einrichten oder die Authentifizierung bei deinem 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 findest du unter Erstellen von Aktionen.

Runner

Ein Runner ist ein Server, auf dem deine Workflows ausgeführt werden, wenn sie ausgelöst werden. Ein Runner kann immer nur einen Auftrag ausführen. Für GitHub AE musst du eigene Runner hosten. Weitere Informationen findest du unter Deinen eigenen Runner hosten.

Erstellen eines Beispielworkflows

In GitHub Actions werden Workflows mithilfe der YAML-Syntax definiert. Die einzelnen Workflows werden in deinem Coderepository jeweils als separate YAML-Datei in einem Verzeichnis mit dem Namen .github/workflows gespeichert.

Du kannst in deinem Repository einen Beispielworkflow erstellen, der immer dann automatisch eine Reihe von Befehlen auslöst, wenn Code per Push übertragen wird. In diesem Workflow checkt GitHub Actions den per Push übertragenen Code aus, installiert das Testframework bats und führt einen einfachen Befehl aus, um die bats-Version auszugeben: bats -v.

  1. Erstelle in deinem Repository das Verzeichnis .github/workflows/, um die Workflowdateien zu speichern.

  2. Erstelle im Verzeichnis .github/workflows/ eine neue Datei mit dem Namen learn-github-actions.yml, und füge den folgenden Code hinzu:

    YAML
    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - uses: actions/setup-node@v3
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
  3. Führe für diese Änderungen einen Commit aus, und übertrage sie per Push in dein GitHub-Repository.

Die neue GitHub Actions-Workflowdatei ist jetzt in deinem Repository installiert und wird immer dann automatisch ausgeführt, wenn eine Änderung per Push in dein Repository übertragen wird. Informationen zum Ausführungsverlauf eines Workflows findest du unter Anzeigen der Aktivität einer Workflowausführung.

Grundlegendes zu Workflowdateien

In diesem Abschnitt wird anhand der einzelnen Zeilen des Einführungsbeispiels erläutert, wie du mithilfe der YAML-Syntax eine Workflowdatei erstellst.

name: learn-github-actions
Optional: Der Name des Workflows, der auf der Registerkarte „Aktionen“ im GitHub-Repository angezeigt wird.
on: [push]
Gibt den Trigger für diesen Workflow an. In diesem Beispiel wird das Ereignis push verwendet. Daher wird immer dann eine Workflowausführung ausgelöst, wenn eine Änderung per Push in das Repository übertragen oder ein Pull Request gemergt wird. Dies wird durch einen Push an jeden beliebigen Branch ausgelöst. Unter Workflowsyntax für GitHub Actions findest du Syntaxbeispiele, die nur bei Pushes an bestimmte Branches, Pfade oder Tags ausgeführt werden.
jobs:
Gruppiert alle Aufträge, die im Workflow learn-github-actions ausgeführt werden.
check-bats-version:
Definiert einen Auftrag mit dem Namen check-bats-version. Die Eigenschaften des Auftrags werden durch die untergeordneten Schlüssel definiert.
  runs-on: ubuntu-latest
Konfiguriert den Auftrag, der für die neueste Version eines Ubuntu Linux-Runners ausgeführt werden soll. Dies bedeutet, dass der Auftrag auf einer neuen, von GitHub gehosteten VM ausgeführt wird. Syntaxbeispiele mit anderen Runnern findest du unter Workflowsyntax für GitHub Actions.
  steps:
Gruppiert alle Schritte, die im Auftrag check-bats-version ausgeführt werden. Alle Elemente in diesem Abschnitt stellen separate Aktionen oder Shellskripts dar.
    - uses: actions/checkout@v3
Das uses-Schlüsselwort gibt an, dass mit diesem Schritt v3 der Aktion actions/checkout ausgeführt wird. Mit dieser Aktion wird dein Repository in den Runner ausgecheckt. Dadurch kannst du Skripts oder andere Aktionen für deinen Code ausführen (z. B. Build- und Testtools). Verwende die Auscheckaktion bei jeder Ausführung deines Workflows für den Code des Repositorys.
    - uses: actions/setup-node@v3
      with:
        node-version: '14'
In diesem Schritt wird mit der Aktion actions/setup-node@v3 die angegebene Node.js-Version installiert (in diesem Beispiel v14). Dadurch werden die Befehle node und npm dem PATH-Element hinzugefügt.
    - run: npm install -g bats
Mit dem run-Schlüsselwort wird der Auftrag angewiesen, einen Befehl im Runner auszuführen. In diesem Fall installierst du das Softwaretestpaket bats mithilfe von npm.
    - run: bats -v
Zuletzt führst du den bats-Befehl mit einem Parameter aus, der die Softwareversion ausgibt.

Visualisieren der Workflowdatei

Im folgenden Diagramm siehst du die zuvor erstellte Workflowdatei und die hierarchische Organisation der GitHub Actions-Komponenten. In jedem Schritt wird eine einzelne Aktion oder ein einzelnes Shellskript ausgeführt. In den Schritten 1 und 2 werden Aktionen ausgeführt, in den Schritten 3 und 4 Shellskripts. Weitere vordefinierte Aktionen für deine Workflows findest du unter Suchen und Anpassen von Aktionen.

Diagramm: Trigger, Runner und Auftrag eines Workflows. Der Auftrag ist in vier Schritte unterteilt.

Anzeigen der Aktivität für eine Workflowausführung

Wenn dein Workflow ausgelöst wird, wird eine Workflowausführung erstellt, die den Workflow ausführt. Nachdem eine Workflowausführung gestartet wurde, wird auf GitHub eine grafische Darstellung des Ausführungsfortschritts sowie der Aktivitäten der einzelnen Schritte dargestellt.

  1. Navigiere auf dein Unternehmen zur Hauptseite des Repositorys. 1. Klicke unter dem Namen deines Repositorys auf Aktionen. Registerkarte „Aktionen“ auf der Navigationsleiste des Hauptrepositorys 1. Klicke in der linken Seitenleiste auf den Workflow, den Du sehen willst.

    Screenshot der linken Randleiste der Registerkarte „Aktionen“. Ein Workflow, „CodeQL“, ist dunkelorange umrandet. 1. Klicke in der Liste der Workflowausführungen auf den Namen der Ausführung, um die Zusammenfassung der Workflowausführung anzuzeigen.

  2. Klicke auf der linken Randleiste oder im Visualisierungsdiagramm auf den Auftrag, den du anzeigen möchtest.

  3. Klicke auf den Schritt, um seine Ergebnisse anzuzeigen.

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 zu CI-Workflows (Continuous Integration) zum Erstellen und Testen deines Codes findest du unter Automatisieren von Builds und Tests.
  • Informationen zum Erstellen und Veröffentlichen von Paketen findest du unter Veröffentlichen von Paketen.
  • Informationen zum Bereitstellen von Projekten findest du unter Bereitstellung.
  • Informationen zum Automatisieren von Aufgaben und Prozessen auf GitHub findest du unter Verwalten von Issues und Pull Requests.
  • Beispiele, die komplexere Features von GitHub Actions veranschaulichen, darunter viele der oben genannten Anwendungsfälle, findest du unter Beispiele. Du erfährst anhand detaillierter Beispiele, wie du deinen Code auf einem Runner testest, auf die GitHub-CLI zugreifst und erweiterte Funktionen wie Parallelität und Testmatrizen verwendest.

Kontaktaufnahme mit dem Support

Wenn du Hilfe im Zusammenhang mit der Workflowkonfiguration benötigst, z. B. zur Syntax, zu von GitHub gehosteten Runnern oder zum Erstellen von Aktionen, suche in der GitHub Community-Kategorie GitHub Actions und GitHub Packages nach einem vorhandenen Thema, oder starte ein neues Thema.

Wenn du Feedback oder Feature-Anfragen zu GitHub Actions abgeben möchtest, teile diese in den GitHub Community-Diskussionen zu GitHub Actions.

Wende dich in den folgenden Fällen an den deine Unternehmensbesitzer*innen, unabhängig davon, ob deine Nutzung oder beabsichtigte Nutzung in die Nutzungseinschränkungskategorien fällt:

  • Du bist der Meinung, dass dein Konto ungerechtfertigt eingeschränkt wurde
  • Beim Ausführen einer deiner Aktionen tritt ein unerwarteter Fehler auf
  • Es tritt eine Situation ein, in der das tatsächliche Verhalten nicht dem erwarteten (jedoch nicht immer dokumentierten) Verhalten entspricht

Weitere Informationsquellen