Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Informationen zu Workflows

Hier findest du eine allgemeine Übersicht über GitHub Actions-Workflows, einschließlich von Triggern, der Syntax und erweiterten Features.

Informationen zu 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.

Grundlagen des Workflows

Ein Workflow muss die folgenden grundlegenden Komponenten enthalten:

  1. Ein oder mehrere Ereignisse, die den Workflow auslösen
  2. Ein oder mehrere Aufträge, die jeweils auf einem Runnercomputer ausgeführt werden, und eine Reihe von Schritten ausführen.
  3. Jeder Schritt kann entweder ein Skript ausführen, das du definierst, oder eine Aktion. Mit dieser wiederverwendbaren Erweiterung kannst du deinen Workflow vereinfachen.

Weitere Informationen zu diesen grundlegenden Komponenten findest du unter Grundlegendes zu GitHub Actions.

Übersicht über Workflow

Auslösen eines Workflows

Workflowtrigger sind Ereignisse, die dazu führen, dass ein Workflow ausgeführt wird. Dabei kann es sich um folgende Ereignisse handeln:

  • Ereignisse, die im Repository deines Workflows auftreten
  • Ereignisse, die außerhalb von GitHub Enterprise Server auftreten und ein repository_dispatch-Ereignis in GitHub Enterprise Server auslösen
  • Geplante Zeiten
  • Manuell

Du kannst deinen Workflow so konfigurieren, dass er ausgeführt wird, wenn ein Push an den Standardzweig deines Repositorys durchgeführt, ein Release erstellt oder ein Issue geöffnet wird.

Weitere Informationen findest du unter Auslösen eines Workflows. Eine vollständige Liste der Ereignisse findest du unter Ereignisse zum Auslösen von Workflows.

Syntax für Workflows

Ein Workflow wird mithilfe von YAML definiert. Eine vollständige Referenz der YAML-Syntax für die Erstellung von Workflows findest du unter Workflowsyntax für GitHub Actions.

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.

Übersicht über Workflow

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 your GitHub Enterprise Server instance zur Hauptseite des Repositorys.

  2. Klicke unter dem Repositorynamen auf Aktionen.

    Navigieren zum Repository

  3. Klicke in der linken Seitenleiste auf den Workflow, den Du sehen willst.

    Screenshot der Workflowergebnisse

  4. Klicke unter „Workflow runs" (Workflow-Ausführungen) auf den Namens des Ausführung, die du sehen willst.

    Screenshot der Workflowausführungen

  5. Wähle unter Aufträge oder im Visualisierungsdiagramm den Auftrag aus, den du anzeigen möchtest.

    Auswählen des Auftrags

  6. Zeige die Ergebnisse der einzelnen Schritte an.

    Screenshot der Details zur Workflowausführung

Weitere Informationen zum Verwalten von Workflowausführungen, zum Beispiel zur erneuten Ausführung, zum Abbruch oder zur Löschung, findest du unter Verwalten von Workflowausführungen.

Verwenden von Startworkflows

GitHub bietet vordefinierte Startworkflows, die du anpassen kannst, um deinen eigenen Continuous Integration-Workflow zu erstellen. GitHub Enterprise Server analysiert deinen Code und zeigt dir CI-Startworkflows an, die für dein Repository nützlich sein könnten. Wenn Dein Repository beispielsweise Node.js-Code enthält, werden Vorschläge für Node.js-Projekte angezeigt. Du kannst Startworkflows als Ausgangspunkt verwenden, um deinen eigenen benutzerdefinierten Workflow zu erstellen, oder du kannst sie unverändert übernehmen.

Eine vollständige Liste aller Startworkflows findest du im actions/starter-workflows-Repository auf your GitHub Enterprise Server instance.

Weitere Informationen zum Verwenden und Erstellen von Startworkflows findest du unter Verwenden von Startworkflows und Erstellen von Startworkflows für deine Organisation.

Erweiterte Workflowfeatures

In diesem Abschnitt werden einige erweiterte Features von GitHub Actions kurz erläutert, mit denen du komplexere Workflows erstellen kannst.

Speichern von Geheimnissen

Wenn deine Workflows vertrauliche Daten wie Kennwörter oder Zertifikate verwenden, kannst du diese auf GitHub als Geheimnisse speichern und dann in deinen Workflows als Umgebungsvariablen verwenden. Das bedeutet, dass du Workflows erstellen und freigeben kannst, ohne vertrauliche Werte direkt in die YAML-Quelle des Workflows einbetten zu müssen.

In diesem Beispielauftrag wird gezeigt, wie du auf ein vorhandenes Geheimnis als Umgebungsvariable verweisen und es als Parameter an einen Beispielbefehl senden kannst.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

Weitere Informationen findest du unter Verschlüsselte Geheimnisse.

Erstellen abhängiger Aufträge

Die Aufträge in deinem Workflow werden standardmäßig gleichzeitig ausgeführt. Wenn du also über einen Auftrag verfügst, der nur ausgeführt werden muss, nachdem ein anderer Auftrag ausgeführt wurde, kannst du das Schlüsselwort needs verwenden, um diese Abhängigkeit zu erstellen. Wenn einer der Aufträge fehlschlägt, werden alle abhängigen Aufträge übersprungen. Wenn die Aufträge jedoch fortgesetzt werden sollen, kannst du dies mithilfe der bedingten Anweisung if definieren.

In diesem Beispiel werden die setup-, build- und test-Aufträge in Serien ausgeführt, wobei build und test von dem erfolgreichen Abschluss des vorangehenden Auftrags abhängen:

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

Weitere Informationen findest du unter Definieren von erforderlichen Aufträgen.

Verwenden einer Matrix

Mithilfe einer Matrixstrategie kannst du Variablen in einer Auftragsdefinition verwenden, um automatisch mehrere Auftragsausführungen zu erstellen, die auf Kombinationen dieser Variablen basieren. Mithilfe einer Matrixstrategie kannst du deinen Code beispielsweise in mehreren Versionen einer Sprache oder auf mehreren Betriebssystemen testen. Die Matrix wird mithilfe des Schlüsselworts strategy erstellt, das die Buildoptionen als Array empfängt. In dieser Matrix wird der Auftrag beispielsweise mehrmals ausgeführt, wobei verschiedene Versionen von Node.js verwendet werden:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [12, 14, 16]
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}

Weitere Informationen findest du unter Verwenden einer Matrix für deine Aufträge.

Abhängigkeiten „cachen“ (zwischenspeichern)

Wenn deine Aufträge regelmäßig Abhängigkeiten wiederverwenden, kannst du diese Dateien zwischenspeichern, um die Leistung zu verbessern. Sobald der Cache erstellt wurde, ist er für alle Workflows im gleichen Repository verfügbar.

In diesem Beispiel wird veranschaulicht, wie das Verzeichnis ~/.npm zwischengespeichert wird:

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v3
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

Weitere Informationen findest du unter Zwischenspeichern von Abhängigkeiten zum Beschleunigen von Workflows.

Datenbanken und Service-Container verwenden

Wenn für deinen Auftrag eine Datenbank oder ein Cachedienst erforderlich ist, kannst du das Schlüsselwort services verwenden, um einen temporären Container zum Hosten des Diensts zu erstellen. Der resultierende Container steht dann allen Schritten in diesem Auftrag zur Verfügung und wird entfernt, wenn der Auftrag abgeschlossen wurde. In diesem Beispiel wird veranschaulicht, wie ein Auftrag services verwenden kann, um einen postgres-Container zu erstellen, und dann node nutzt, um eine Verbindung mit diesem Dienst herzustellen.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

Weitere Informationen findest du unter Verwenden von Containerdiensten.

Verwenden von Bezeichnungen zum Weiterleiten von Workflows

Wenn du sicher sein möchtest, dass ein bestimmter Runnertyp deinen Auftrag verarbeitet, kannst du mithilfe von Bezeichnungen steuern, wo die Aufträge ausgeführt werden. Du kannst einem selbstgehosteten Runner zusätzlich zur Standardbezeichnung self-hosted weitere Bezeichnungen hinzufügen. Dann kannst du auf diese Bezeichnungen in deinem YAML-Workflow verweisen, um sicherzustellen, dass der Auftrag auf vorhersehbare Weise weitergeleitet wird. GitHub-gehostete Runner wurden vordefinierte Bezeichnungen zugewiesen.

In diesem Beispiel wird gezeigt, wie ein Workflow Bezeichnungen verwenden kann, um den gewünschten Runner anzugeben:

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

Ein Workflow wird nur auf einem Runner ausgeführt, der alle Bezeichnungen im runs-on-Array hat. Der Auftrag wird bevorzugt an einen inaktiven, selbstgehosteten Runner mit den angegebenen Bezeichnungen weitergeleitet.

Weitere Informationen zu selbstgehosteten Runnerbezeichnungen findest du unter Verwenden von Bezeichnungen mit selbstgehosteten Runnern.

Wiederverwenden von Workflows

Du kannst Workflows für deine Organisation öffentlich oder privat freigeben. Dazu musst du einen Workflow aus einem anderen Workflow aufrufen. So kannst du Workflows wiederverwenden, duplizieren und einfacher verwalten. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Verwenden von Umgebungen

Du kannst Umgebungen mit Schutzregeln und Geheimnissen konfigurieren, um die Ausführung von Aufträgen in einem Workflow zu steuern. Jeder Auftrag in einem Workflow kann auf eine einzelne Umgebung verweisen. Alle für die Umgebung konfigurierten Schutzregeln müssen eingehalten werden, bevor ein Auftrag, der auf die Umgebung verweist, an einen Runner gesendet wird. Weitere Informationen findest du unter Verwenden von Umgebungen für die Bereitstellung.