About 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 deiner Anwendung bei jeder Erstellung eines Release
Hinzufügen einer Bezeichnung, wenn ein neues Issue geöffnet wird

Workflow basics

A workflow must contain the following basic components:

One or more events that will trigger the workflow.
One or more jobs, each of which will execute on a runner machine and run a series of one or more steps.
Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

For more information on these basic components, see Understanding GitHub Actions.

Diagram of an event triggering Runner 1 to run Job 1, which triggers Runner 2 to run Job 2. Each of the jobs is broken into multiple steps.

Triggering a workflow

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 auftreten und ein repository_dispatch-Ereignis in GitHub 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.

For more information, see Triggering a workflow, and for a full list of events, see Ereignisse zum Auslösen von Workflows.

Workflow syntax

Workflows are defined using YAML. For the full reference of the YAML syntax for authoring workflows, see Workflowsyntax für GitHub Actions.

For more on managing workflow runs, such as re-running, cancelling, or deleting a workflow run, see Managing workflow runs and deployments.

Using workflow templates

GitHub bietet vordefinierte Workflowvorlagen, die du unverändert übernehmen oder anpassen kannst, um einen eigenen Workflow zu erstellen. GitHub analysiert den Code und zeigt Workflowvorlagen 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.

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

CI: Workflows für Continuous Integration
Bereitstellungen: Bereitstellungsworkflows
Automatisierung: Workflows zur Automatisierung
Codeüberprüfung: Workflows zur Codeüberprüfung
Seiten: Seitenworkflows

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.

Advanced workflow features

This section briefly describes some of the advanced features of GitHub Actions that help you create more complex workflows.

Storing secrets

If your workflows use sensitive data, such as passwords or certificates, you can save these in GitHub as secrets and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the workflow's YAML source.

This example job demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.

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

For more information, see Using secrets in GitHub Actions.

Creating dependent jobs

By default, the jobs in your workflow all run in parallel at the same time. If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement.

In this example, the setup, build, and test jobs run in series, with build and test being dependent on the successful completion of the job that precedes them:

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

For more information, see Using jobs in a workflow.

Using a 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. The matrix is created using the strategy keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of Node.js:

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

For more information, see Running variations of jobs in a workflow.

Caching dependencies

If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.

This example demonstrates how to cache the ~/.npm directory:

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v4
        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 }}-

For more information, see Caching dependencies to speed up workflows.

Using databases and service containers

If your job requires a database or cache service, you can use the services keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use services to create a postgres container, and then use node to connect to the service.

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

For more information, see Using containerized services.

Using labels to route workflows

If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of self-hosted. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way. GitHub-hosted runners have predefined labels assigned.

This example shows how a workflow can use labels to specify the required runner:

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

A workflow will only run on a runner that has all the labels in the runs-on array. The job will preferentially go to an idle self-hosted runner with the specified labels. If none are available and a GitHub-hosted runner with the specified labels exists, the job will go to a GitHub-hosted runner.

To learn more about self-hosted runner labels, see Using labels with self-hosted runners.

To learn more about GitHub-hosted runner labels, see Using GitHub-hosted runners.

Reusing workflows

Du kannst einen Workflow aus einem anderen Workflow aufrufen. So kannst du Workflows wiederverwenden, duplizieren und einfacher verwalten. Weitere Informationen finden Sie unter Reusing workflows.

Security hardening for 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 finden Sie unter Using GitHub's security features to secure your use of GitHub Actions.

Using environments

You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see Managing environments for deployment.

About workflows

In diesem Artikel