Informationen zu Workflows

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

In diesem Artikel

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

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.

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.

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

Workflows werden 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.

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 und Bereitstellungen.

Verwenden von Workflowvorlagen

GitHub bietet vordefinierte Workflowvorlagen, die Sie unverändert übernehmen oder anpassen können, um einen eigenen Workflow zu erstellen. GitHub Enterprise Cloud analysiert den Code und zeigt Workflowvorlagen an, die für Ihr Repository nützlich sein könnten. Wenn Dein Repository beispielsweise Node.js-Code enthält, werden Vorschläge für Node.js-Projekte angezeigt.

Diese Workflowvorlagen ermöglichen einen schnellen Einstieg und bieten verschiedene Konfigurationen, wie z. B.:

Sie können diese Workflows als Ausgangspunkt nutzen, um eigene benutzerdefinierte Workflows zu erstellen, oder sie unverändert übernehmen. Die vollständige Liste der Workflowvorlagen können Sie im Repository der Aktions-/Starter-Workflows durchsuchen. Weitere Informationen findest du unter Verwenden von Workflowvorlagen.

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 Verwenden von Geheimnissen in GitHub-Aktionen.

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: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

Weitere Informationen findest du unter Ausführen von Variationen von Aufträgen in einem Workflow.

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:20-bookworm-slim
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4
      - 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. Anschließend können Sie in Ihrem YAML-Workflow auf diese Bezeichnungen verweisen und sicherstellen, dass der Job vorhersehbar weitergeleitet wird. GitHub-gehostete Runner haben 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 Verwenden von auf GitHub gehosteten 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.

Sicherheitshärtung für Workflows

GitHub bietet Sicherheitsfeatures, mit denen Sie die Sicherheit Ihrer Workflows erhöhen können. Sie können {die integrierten Features von GitHub verwenden, um sicherzustellen, dass Sie über Sicherheitsrisiken in den von Ihnen genutzten Aktionen benachrichtigt werden, oder um den Prozess der Aufbewahrung der Aktionen in Ihren Workflows auf dem neuesten Stand zu halten. Weitere Informationen findest du unter Verwenden der Sicherheitsfeatures von GitHub zum Sichern Ihrer Verwendung von GitHub-Aktionen.

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 Verwalten von Umgebungen für die Bereitstellung.