Informationen zu Workflows

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.

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 Cloud auftreten und ein repository_dispatch-Ereignis in GitHub Enterprise Cloud 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, und eine vollständige Liste von Ereignissen ist unter Ereignisse zum Auslösen von Workflows verfügbar.

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
   run-name: ${{ github.actor }} is learning 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

run-name: ${{ github.actor }} is learning 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

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.

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 GitHub.com zur Hauptseite des Repositorys. 1. Klicke unter dem Namen deines Repositorys auf Aktionen. 1. Klicke in der linken Seitenleiste auf den Workflow, den Du sehen willst.

   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.

Weitere Informationen zum Verwalten von Workflowausführungen (z. B. erneutes Ausführen, Abbrechen oder Löschen einer Workflowausführung) 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 Cloud 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.

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 Verwenden von Aufträgen in einem Workflow.

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 von Matrizen 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 Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen.

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. Wenn keine verfügbar sind und ein von GitHub gehosteter Runner mit den angegebenen Bezeichnungen vorhanden ist, wird der Auftrag an einen von GitHub gehosteten Runner weitergeleitet.

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

Weitere Informationen zu den von GitHub gehosteten Runnerbezeichnungen findest du unter Informationen zu von GitHub gehostete 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 finden Sie 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.