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:
- Ein oder mehrere Ereignisse, die den Workflow auslösen
- Ein oder mehrere Aufträge, die jeweils auf einem Runnercomputer ausgeführt werden, und eine Reihe von Schritten ausführen.
- 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 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, 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
.
-
Erstelle in deinem Repository das Verzeichnis
.github/workflows/
, um die Workflowdateien zu speichern. -
Erstelle im Verzeichnis
.github/workflows/
eine neue Datei mit dem Namenlearn-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.
# 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.
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.
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 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 Ihre 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 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 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@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.
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 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 Verwenden von Umgebungen für die Bereitstellung.