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