Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
Configuring workflow events
You can configure workflows to run for one or more events using the on
workflow syntax. Weitere Informationen finden Sie unter „Workflow-Syntax für GitHub Actions“.
Example: Using a single event
# Triggered when code is pushed to any branch in a repository
on: push
Example: Using a list of events
# Triggers the workflow on push or pull request events
on: [push, pull_request]
Example: Using multiple events with activity types or configuration
Wenn Du Aktivitätstypen oder Konfigurationen für ein Ereignis angeben musst, musst Du jedes Ereignis separat konfigurieren. Du musst einen Doppelpunkt (:
) an alle Ereignisse anhängen, einschließlich Ereignisse ohne Konfiguration.
on:
# Trigger the workflow on push or pull request,
# but only for the main branch
push:
branches:
- main
pull_request:
branches:
- main
# Also trigger on page_build, as well as release created events
page_build:
release:
types: # This configuration does not affect the page_build event above
- created
Hinweis: Du kannst einen neuen Workflow-Lauf nicht mithilfe des GITHUB_TOKEN
anstoßen. Weitere Informationen findest Du unter „Neue Workflows mit einem persönlichen Zugriffstoken anstoßen“.
Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:
-
An event occurs on your repository, and the resulting event has an associated commit SHA and Git ref.
-
Das Verzeichnis
.github/workflows
in Deinem Repository wird nach Workflow-Dateien des zugehörigen Commit-SHA oder der zugehörigen Git Ref durchsucht. Die Workflow-Dateien müssen in diesem Commit-SHA oder dieser Git Ref vorhanden sein, um berücksichtigt zu werden.Wenn zum Beispiel das Ereignis in einem bestimmten Repository-Zweig aufgetreten ist, müssen die Workflow-Dateien im Repository dieses Zweiges vorhanden sein.
-
Die Workflow-Dateien für diesen Commit-SHA und diese Git Ref werden überprüft und für alle Workflows, deren
on:
-Werte zu dem auslösenden Ereignis passen, wird ein neuer Workflow-Lauf angestoßen.Der Workflow läuft auf dem Code Deines Repositorys mit dem selben Commit-SHA und derselben Git Ref wie das auslösende Ereignis. Wenn ein Workflow läuft, setzt GitHub Enterprise Server die Umgebungsvariablen
GITHUB_SHA
(Commit-SHA) undGITHUB_REF
(Git Ref) in der Umgebung auf dem Runner. Weitere Informationen findest Du unter „Umgebungsvariablen verwenden“.
Geplante Ereignisse
The schedule
event allows you to trigger a workflow at a scheduled time.
Note: The schedule
event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
Zeitplan
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
– | – | Letzter Commit im Standard-Branch | Standardbranch |
Du kannst einen Workflow mit Hilfe von POSIX cron syntax so planen, dass er zu bestimmten UTC-Zeiten ausgeführt wird. Geplante Workflows laufen auf dem jüngsten Commit auf dem Standard- oder Basisbranch. Das kürzeste Intervall, in dem Sie geplante Workflows ausführen können, ist einmal alle 5 Minuten.
This example triggers the workflow every day at 5:30 and 17:30 UTC:
on:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '30 5,17 * * *'
Die Cron-Syntax umfasst fünf durch Leerzeichen getrennte Felder, die jeweils eine Zeiteinheit darstellen.
┌───────────── Minute (0–59)
│ ┌───────────── Stunde (0–23)
│ │ ┌───────────── Tag (1–31)
│ │ │ ┌───────────── Monat (1–12 oder JAN–DEZ)
│ │ │ │ ┌───────────── Wochentag (0–6 oder SON–SAM)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
In den fünf Feldern stehen die folgenden Operatoren zur Auswahl:
Operator | Beschreibung | Beispiel |
---|---|---|
* | Beliebiger Wert | * * * * * wird jeden Tag jede Minute ausgeführt. |
, | Trennzeichen in Werteliste | 2,10 4,5 * * * wird jeden Tag bei Minute 2 und 10 der 4. und 5. Stunde ausgeführt. |
- | Wertebereich | 0 4-6 * * * wird bei Minute 0 der 4., 5. und 6. Stunde ausgeführt. |
/ | Schrittwerte | 20/15 * * * * wird alle 15 Minuten ausgeführt, von Minute 20 bis Minute 59 (also bei Minute 20, 35 und 50). |
Hinweis: GitHub Actions bietet keine Unterstützung für die nicht standardmäßige Syntax @yearly
, @monthly
, @weekly
, @daily
, @hourly
und @reboot
.
Mit crontab guru können Sie die Cron-Syntax erzeugen und den Ausführungszeitpunkt bestätigen. Als Einstiegshilfe steht eine Liste mit crontab-guru-Beispielen bereit.
Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, please see "Notifications for workflow runs."
Manual events
You can manually trigger workflow runs. To trigger specific workflows in a repository, use the workflow_dispatch
event. To trigger more than one workflow in a repository and create custom events and event types, use the repository_dispatch
event.
workflow_dispatch
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_dispatch | – | Letzter Commit im Branch GITHUB_REF | Branch, der den Dispatch empfangen hat |
You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. Wenn der Workflow ausgeführt wird, können Sie auf die Eingabewerte im github.event.inputs
Kontextzugreifen. Weitere Informationen finden Sie unter „Kontexte“.
You can manually trigger a workflow run using the GitHub API and from GitHub. For more information, see "Manually running a workflow."
When you trigger the event on GitHub, you can provide the ref
and any inputs
directly on GitHub. For more information, see "Using inputs and outputs with an action."
To trigger the custom workflow_dispatch
webhook event using the REST API, you must send a POST
request to a GitHub API endpoint and provide the ref
and any required inputs
. For more information, see the "Create a workflow dispatch event" REST API endpoint.
Beispiel
To use the workflow_dispatch
event, you need to include it as a trigger in your GitHub Actions workflow file. The example below only runs the workflow when it's manually triggered:
on: workflow_dispatch
Example workflow configuration
In diesem Beispiel wird der Name
definiert und ein- und zu Hause verwendet, und sie werden mit den Kontexten <code>github.event.inputs.name
und github.event.inputs.home
gedruckt. If a home
isn't provided, the default value 'The Octoverse' is printed.
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in{{ github.event.inputs.home }}!"
repository_dispatch
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
repository_dispatch | – | Letzter Commit im Standard-Branch | Standard-Branch |
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Mit der GitHub Enterprise Server-API können Sie das Webhook-Ereignis repository_dispatch
auslösen, wenn ein Workflow für eine Aktivität ausgelöst werden soll, die außerhalb von GitHub abläuft. For more information, see "Create a repository dispatch event."
Soll das benutzerdefinierte Webhook-Ereignis repository_dispatch
ausgelöst werden, senden Sie eine POST
-Anfrage an einen GitHub Enterprise Server-API-Endpunkt, und geben Sie den Namen für einen event_type
als Beschreibung für den Aktivitätstyp an. Soll ein Workflow-Lauf ausgelöst werden, konfigurieren Sie außerdem den Workflow für die Verwendung des Ereignisses repository_dispatch
.
Beispiel
Standardmäßig lösen alle event_types
einen Workflow aus. Du kannst Deinen Workflow darauf beschränken, zu laufen, wenn ein bestimmter Wert als event_type
in der Webhoo-Nutzlast des repository_dispatch
gesendet wird. Du definierst die Ereignistypen, die in der Nutzlast des repository_dispatch
gesendet werden, wenn Du das Repositorydispatch-Ereignis erstellst.
on:
repository_dispatch:
types: [opened, deleted]
Webhook-Ereignisse
You can configure your workflow to run when webhook events are generated on GitHub Enterprise Server. Einige Ereignisse werden von mehreren Aktivitätstypen ausgelöst. Wird ein Ereignis von mehreren Aktivitätstypen ausgelöst, können Sie die Aktivitätstypen angeben, die die Ausführung des Workflows auslösen sollen. For more information, see "Webhooks."
Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "Webhook events and payloads."
check_run
Führt den Workflow aus, wenn das Ereignis check_run
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Check runs."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_run | - created - rerequested - completed | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
For example, you can run a workflow when a check run has been rerequested
or completed
.
on:
check_run:
types: [rerequested, completed]
check_suite
Führt den Workflow aus, wenn das Ereignis check_suite
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Check suites."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Hinweis: Um rekursive Workflows zu verhindern, löst dieses Ereignis keine Workflows aus, wenn die Prüfsuite von GitHub Actions erstellt wurde.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_suite | - completed - requested - rerequested | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Sie können einen Workflow beispielsweise ausführen, wenn eine Prüfsuite erneut angefordert (rerequested
) oder abgeschlossen (completed
) wurde.
on:
check_suite:
types: [rerequested, completed]
create
Führt den Workflow aus, wenn ein Benutzer einen Branch oder ein Tag erstellt, wodurch das Ereignis create
ausgelöst wird. For information about the REST API, see "Create a reference."
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
create | – | Letzter Commit im erstellten Branch oder Tag | Erstellter Branch oder Tag |
Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis create
eintritt.
on:
create
delete
Führt den Workflow aus, wenn ein Benutzer einen Branch oder ein Tag löscht, wodurch das Ereignis delete
ausgelöst wird. For information about the REST API, see "Delete a reference."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
delete | – | Letzter Commit im Standard-Branch | Standard-Branch |
Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis delete
eintritt.
on:
delete
deployment
Führt den Workflow aus, wenn ein Benutzer eine Bereitstellung erstellt, wodurch das Ereignis deployment
ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "Deployments."
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment | – | Bereitzustellender Commit | Bereitzustellender Branch oder Tag (leer bei Commit) |
Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis deployment
eintritt.
on:
deployment
deployment_status
Führt den Workflow aus, wenn ein Dritter einen Bereitstellungsstatus angibt, wodurch das Ereignis deployment_status
ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "Create a deployment status."
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment_status | – | Bereitzustellender Commit | Bereitzustellender Branch oder Tag (leer bei Commit) |
Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis deployment_status
eintritt.
on:
deployment_status
Note: When a deployment status's state is set to inactive
, a webhook event will not be created.
Fork
Führt den Workflow aus, wenn ein Benutzer per „Fork“ (Gabel-Kopie) ein Repository kopiert, wodurch das Ereignis fork
ausgelöst wird. For information about the REST API, see "Create a fork."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Fork | – | Letzter Commit im Standard-Branch | Standard-Branch |
Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis fork
eintritt.
on:
fork
gollum
Führt den Workflow aus, wenn ein Benutzer eine Wiki-Seite erstellt oder aktualisiert, wodurch das Ereignis gollum
ausgelöst wird.
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
gollum | – | Letzter Commit im Standard-Branch | Standard-Branch |
Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis gollum
eintritt.
on:
gollum
issue_comment
Führt Deinen Workflow jedes Mal aus, wenn das Ereignis issue_comment
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Issue comments."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
issue_comment | - created - edited - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Problemkommentar erstellt (created
) oder gelöscht (deleted
) wurde.
on:
issue_comment:
types: [created, deleted]
The issue_comment
event occurs for comments on both issues and pull requests. To determine whether the issue_comment
event was triggered from an issue or pull request, you can check the event payload for the issue.pull_request
property and use it as a condition to skip a job.
For example, you can choose to run the pr_commented
job when comment events occur in a pull request, and the issue_commented
job when comment events occur in an issue.
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on PR #${{ github.event.issue.number }}"
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on issue #${{ github.event.issue.number }}"
Issues (Lieferungen)
Führt den Workflow aus, wenn das Ereignis issues
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Issues."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Issues (Lieferungen) | - opened - edited - deleted - transferred - pinned - unpinned - closed - reopened - assigned - unassigned - labeled - unlabeled - locked - unlocked - milestoned - demilestoned | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Problem geöffnet (opened
) oder bearbeitet (edited
) wurde oder wenn dafür ein Meilenstein gesetzt wurde (milestoned
).
on:
issues:
types: [opened, edited, milestoned]
Kennzeichnung
Führt den Workflow aus, wenn das Ereignis label
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Labels."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Kennzeichnung | - created - edited - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Sie können einen Workflow beispielsweise ausführen, wenn eine Kennzeichnung erstellt (created
) oder gelöscht (deleted
) wurde.
on:
label:
types: [created, deleted]
Meilensteine
Führt Deinen Workflow aus, wenn das Ereignis milestone
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Milestones."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Meilensteine | - created - closed - opened - edited - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn eine Meilenstein geöffnet (opened
) oder gelöscht (deleted
) wurde.
on:
milestone:
types: [opened, deleted]
page_build
Führt den Workflow aus, wenn ein Benutzer einen Push an einen GitHub Enterprise Server-Pages-fähigen Branch vornimmt, wodurch das Ereignis page_build
ausgelöst wird. For information about the REST API, see "Pages."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
page_build | – | Letzter Commit im Standard-Branch | – |
Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis page_build
eintritt.
on:
page_build
project (Projekt)
Führt den Workflow aus, wenn das Ereignis project
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Projects."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project (Projekt) | - created - updated - closed - reopened - edited - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Sie können einen Workflow beispielsweise ausführen, wenn ein Projekt erstellt (created
) oder gelöscht (deleted
) wurde.
on:
project:
types: [created, deleted]
project_card
Führt den Workflow aus, wenn das Ereignis project_card
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Project cards."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_card | - created - moved - converted to an issue- edited - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Sie können einen Workflow beispielsweise ausführen, wenn ein Projektticket geöffnet (opened
) oder gelöscht (deleted
) wurde.
on:
project_card:
types: [created, deleted]
project_column
Führt Deinen Workflow aus, wenn das Ereignis project_column
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Project columns."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_column | - created - updated - moved - deleted | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn eine Projektspalte erstellt (created
) oder gelöscht (deleted
) wurde.
on:
project_column:
types: [created, deleted]
public
Führt Deinen Workflow aus, wenn ein Benutzer ein privates Repository öffentlich macht, wodurch das Ereignis public
ausgelöst wird. For information about the REST API, see "Edit repositories."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
public | – | Letzter Commit im Standard-Branch | Standard-Branch |
Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis public
eintritt.
on:
public
pull_request
Führt Deinen Workflow aus, wenn das Ereignis pull_request
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Pull requests."
Hinweise:
- By default, a workflow only runs when a
pull_request
's activity type isopened
,synchronize
, orreopened
. Sollen Workflows für weitere Aktivitätstypen ausgelöst werden, verwende das Schlüsselworttypes
. - Workflows will not run on
pull_request
activity if the pull request has a merge conflict. The merge conflict must be resolved first.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request | - assigned - unassigned - labeled - unlabeled - opened - edited - closed - reopened - synchronize - converted_to_draft - ready_for_review - locked - unlocked - review_requested - review_request_removed | Letzter Merge-Commit im Branch GITHUB_REF | PR-Merge-Branch refs/pull/:prNumber/merge |
Mit dem Stichwort types
erweitern oder begrenzen Sie die Standard-Aktivitätstypen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise dann ausführen, wenn ein Pull Request zugewiesen (assigned
), geöffnet (opened
), synchronisiert (synchronize
) oder erneut geöffnet (reopened
) wurde.
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
Pull-Request-Ereignisse für geforkte Repositorys
Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.
Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request
an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.
Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.
Mit Ausnahme von GITHUB_TOKEN
werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN
in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."
Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.
pull_request_review
Führt Deinen Workflow aus, wenn das Ereignis pull_request_review
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Pull request reviews."
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review | - submitted - edited - dismissed | Letzter Merge-Commit im Branch GITHUB_REF | PR-Merge-Branch refs/pull/:prNumber/merge |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Pull-Request-Review bearbeitet (edited
) oder verworfen (dismissed
) wurde.
on:
pull_request_review:
types: [edited, dismissed]
Pull-Request-Ereignisse für geforkte Repositorys
Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.
Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request
an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.
Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.
Mit Ausnahme von GITHUB_TOKEN
werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN
in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."
Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.
pull_request_review_comment
Führt den Workflow aus, wenn ein Kommentar zum vereinheitlichten Diff für einen Pull Request geändert wird, wodurch das Ereignis pull_request_review_comment
ausgelöst wird. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see Review comments.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review_comment | - created - edited - deleted | Letzter Merge-Commit im Branch GITHUB_REF | PR-Merge-Branch refs/pull/:prNumber/merge |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Pull-Request-Review-Kommentar erstellt (created
) oder gelöscht (deleted
) wurde.
on:
pull_request_review_comment:
types: [created, deleted]
Pull-Request-Ereignisse für geforkte Repositorys
Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.
Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request
an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.
Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.
Mit Ausnahme von GITHUB_TOKEN
werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN
in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."
Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.
Push
Hinweis: Die Webhook-Nutzlast, die Für GitHub-Aktionen verfügbar ist, enthält im Objekt commit
nicht die Attribute added
, removed
und modified
. Du kannst das vollständige Commit-Objekt mit der REST-API abrufen. For more information, see "Get a commit".
Führt den Workflow aus, wenn ein Benutzer einen Push an einen Repository-Branch durchführt, wodurch das Ereignis push
ausgelöst wird.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Push | – | Gepushter Commit, außer beim Löschen eines Branches (nur beim Standard-Branch) | Aktualisierter Ref |
Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis push
eintritt.
on:
push
registry_package
Führt Deinen Workflow aus, wenn ein Paket veröffentlicht
oder aktualisiert
wird. Weitere Informationen findest Du unter „Pakete mit GitHub Packages verwalten".
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
registry_package | - published - updated | Commit des veröffentlichten Pakets | Branch oder Tag des veröffentlichten Pakets |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Paket veröffentlicht (published
) wurde.
on:
registry_package:
types: [published]
Release
Hinweis: Das Ereignis release
wird für Entwurfsversionen nicht ausgelöst.
Führt Deinen Workflow aus, wenn das Ereignis release
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Releases."
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Release | - published - unpublished - created - edited - deleted - prereleased - released | Letzter Commit in dem bezeichneten Release | Bezeichnung des Releases |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Führe einen Workflow beispielsweise aus, wenn ein Release veröffentlicht (published
) wurde.
on:
release:
types: [published]
Note: The prereleased
type will not trigger for pre-releases published from draft releases, but the published
type will trigger. If you want a workflow to run when stable and pre-releases publish, subscribe to published
instead of released
and prereleased
.
Status
Führt Deinen Workflow aus, wenn sich der Status eines Git-Commit ändert, wodurch das Ereignis status
ausgelöst wird. For information about the REST API, see Statuses.
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Status | – | Letzter Commit im Standard-Branch | – |
Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis status
eintritt.
on:
status
beobachten
Führt Deinen Workflow aus, wenn das Ereignis watch
eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Starring."
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Nutzlast des Webhook-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
beobachten | - started | Letzter Commit im Standard-Branch | Standard-Branch |
Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types
kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
Du kannst einen Workflow beispielsweise ausführen, wenn ein Benutzer ein Repository mit Sternen bewertet, also wenn das Beobachtungsereignis mit dem Aktivitätstyp started
ausgelöst wird.
on:
watch:
types: [started]
To run a workflow job conditionally based on the result of the previous workflow run, you can use the jobs.<job_id>.if
or jobs.<job_id>.steps[*].if
conditional combined with the conclusion
of the previous run. Ein Beispiel:
on:
workflow_run:
workflows: ["Build"]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
...
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
...
Neue Workflows mit einem persönlichen Zugangs-Token auslösen
Wenn Du den GITHUB_TOKEN
des Repository verwendest, um Aufgaben im Auftrag der GitHub Actions App auszuführen, werden die vom GITHUB_TOKEN
ausgelösten Ereignisse keine neue Workflow-Ausführung bereitstellen. Dadurch wird verhindert, dass Du versehentlich rekursive Workflow-Ausführung erstellst. Wenn z. B. eine Workflow-Ausführung Code mit dem GITHUB_TOKEN
des Repository pusht, wird kein neuer Workflow ausgeführt, auch wenn das Repository einen Workflow enthält, welcher konfiguriert ist zur Ausführung wenn push
Ereignisse auftreten. weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN“.
Wenn Du einen Workflow aus einem Workflow-Lauf auslösen möchtest, kannst Du das Ereignis mithilfe eines persönlichen Zugangs-Tokens auslösen. Du musst einen persönlichen Zugangs-Token erstellen und ihn als Geheimnis speichern. Um Dein Nutzungskosten für GitHub Actions zu minimieren, pass auf, dass Du keine rekursiven oder unbeabsichtigten Workflow-Läufe erzeugst. For more information on storing a personal access token as a secret, see "Creating and storing encrypted secrets."