Grundlegendes zu GitHub Actions

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Ü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 Ihre GitHub Enterprise Server-Instance 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. Eine 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 Enterprise Server 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.

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

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@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

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@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

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.

YAML

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions

# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
- uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 20.) This puts both the `node` and `npm` commands in your `PATH`.
- uses: actions/setup-node@v4
with:
node-version: '20'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
- run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
- run: bats -v

name: learn-github-actions

Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.

run-name: ${{ github.actor }} is learning GitHub Actions

Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the github context to display the username of the actor that triggered the workflow run. For more information, see "Workflowsyntax für GitHub Actions."

on: [push]

Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflowsyntax für GitHub Actions."

jobs:

Groups together all the jobs that run in the learn-github-actions workflow.

  check-bats-version:

Defines a job named check-bats-version. The child keys will define properties of the job.

    runs-on: ubuntu-latest

Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Workflowsyntax für GitHub Actions"

    steps:

Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.

      - uses: actions/checkout@v4

The uses keyword specifies that this step will run v4 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

This step uses the actions/setup-node@v4 action to install the specified version of the Node.js. (This example uses version 20.) This puts both the node and npm commands in your PATH.

      - run: npm install -g bats

The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.

      - run: bats -v

Finally, you'll run the bats command with a parameter that outputs the software version.

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions

# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 20.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - 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.

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.

Navigiere auf Ihre GitHub Enterprise Server-Instance zur Hauptseite des Repositorys.
Klicke unter dem Namen deines Repositorys auf Aktionen.
Klicke in der linken Seitenleiste auf den Workflow, den Du sehen willst.
Klicke in der Liste der Workflowausführungen auf den Namen der Ausführung, um die Zusammenfassung der Workflowausführung anzuzeigen.
Klicke auf der linken Randleiste oder im Visualisierungsdiagramm auf den Auftrag, den du anzeigen möchtest.
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:

Eine schnelle Möglichkeit zum Erstellen eines GitHub Actions-Workflows ist unter „Verwenden von Startworkflows“ zu finden.
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.

Weitere Informationen

Informationen zu GitHub Actions für Unternehmen

Grundlegendes zu GitHub Actions

In diesem Artikel