# Ereignisse zum Auslösen von Workflows
Sie können Ihre Workflows so konfigurieren, dass sie ausgeführt werden, wenn eine bestimmte Aktivität bei GitHub eintritt, zu einem geplanten Zeitpunkt oder wenn ein Ereignis außerhalb von GitHub eintritt.
## Informationen zu Ereignissen, die Workflows auslösen
Workflowtrigger sind Ereignisse, die dazu führen, dass ein Workflow ausgeführt wird. Weitere Informationen über die Verwendung von Workflow-Triggern findest du unter [Auslösen eines Workflows](/de/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow).
Einige Ereignisse weisen mehrere Aktivitätstypen auf. Für diese Ereignisse kannst du angeben, welche Aktivitätstypen eine Workflowausführung auslösen. Weitere Informationen darüber, was die einzelnen Aktivitätstypen bedeuten, findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads).
> \[!NOTE]
> Nicht alle Webhook-Ereignisse lösen Workflows aus.
## `branch_protection_rule`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------- | ------------------------------------------ | -------------------------------- | -------------- |
| [`branch_protection_rule`](/de/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`
- `edited`
- `deleted` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#branch_protection_rule). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn Regeln für den Schutz von Branches im Workflow-Repository geändert werden. Weitere Informationen zu Branchschutzregeln findest du unter [Informationen zu geschützten Branches](/de/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). Informationen über die Branch-Schutzregel-APIs findest du unter [Branches](/de/graphql/reference/branches#object-branchprotectionrule) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Branches und deren Einstellungen](/de/rest/branches).
Du kannst beispielsweise einen Workflow ausführen, wenn eine Regel für den Schutz von Branches erstellt (`created`) oder gelöscht (`deleted`) wurde:
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
## `check_run`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------- | -------------- |
| [`check_run`](/de/webhooks/webhook-events-and-payloads#check_run) | - `created`
- `rerequested`
- `completed`
- `requested_action` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#check_run). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Um rekursive Workflows zu verhindern, löst dieses Ereignis keine Workflows aus, wenn die Prüfsuite der Ausführung durch GitHub Actions erstellt wurde oder wenn der Head-SHA der Prüfsuite mit GitHub Actions assoziiert ist.
Führt deinen Workflow aus, wenn Aktivitäten im Zusammenhang mit einer Überprüfungsausführung auftreten. Eine Überprüfungsausführung ist ein einzelner Test, der Teil einer Überprüfungssammlung ist. Informationen findest du unter [Verwenden der REST-API zur Interaktion mit Überprüfungen](/de/rest/guides/using-the-rest-api-to-interact-with-checks). Informationen über die APIs zum Ausführen von Checks findest du unter [Prüfungen](/de/graphql/reference/checks#object-checkrun) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Überprüfungsausführungen](/de/rest/checks/runs).
Du kannst z. B. einen Workflow ausführen, wenn eine Überprüfung erneut angefordert (`rerequested`) oder abgeschlossen (`completed`) wurde.
```yaml
on:
check_run:
types: [rerequested, completed]
```
## `check_suite`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`check_suite`](/de/webhooks/webhook-events-and-payloads#check_suite) | - `completed` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#check_suite). Obwohl nur der Aktivitätstyp `completed` unterstützt wird, bleibt dein Workflow durch Angabe des Aktivitätstyps spezifisch, wenn zukünftig weitere Aktivitätstypen hinzugefügt werden. Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Um rekursive Workflows zu verhindern, löst dieses Ereignis keine Workflows aus, wenn die Prüfsuite von GitHub Actions erstellt wurde oder wenn die Head-SHA der Prüfsuite mit GitHub Actions assoziiert ist.
Führt deinen Workflow aus, wenn eine Überprüfungssammlungsaktivität stattfindet. Eine Überprüfungssammlung ist eine Sammlung von Überprüfungsausführungen, die für einen bestimmten Commit erstellt wurde. Überprüfungssammlungen fassen den Status und das Ergebnis der Überprüfungsausführungen zusammen, die in der Sammlung enthalten sind. Informationen findest du unter [Verwenden der REST-API zur Interaktion mit Überprüfungen](/de/rest/guides/using-the-rest-api-to-interact-with-checks). Informationen zu den APIs der Check-Suite findest du unter [Prüfungen](/de/graphql/reference/checks#object-checksuite) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Prüfsuiten](/de/rest/checks/suites).
Du kannst z. B. einen Workflow ausführen, wenn eine Überprüfung abgeschlossen (`completed`) wurde.
```yaml
on:
check_suite:
types: [completed]
```
## `create`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | --------------- | -------------------------------------------- | -------------------------- |
| [`create`](/de/webhooks/webhook-events-and-payloads#create) | Nicht verfügbar | Letzter Commit im erstellten Branch oder Tag | Erstellter Branch oder Tag |
> \[!NOTE]
> Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags auf einmal erstellst.
Führt deinen Workflow aus, wenn ein Git-Verweis (Git-Verzweigung oder -Tag) im Repository des Workflows erstellt wird. Informationen über die APIs zum Erstellen einer Git-Referenz findest du unter [Git](/de/graphql/reference/git#mutation-createref) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Git-Verweise](/de/rest/git/refs#create-a-reference).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `create` eintritt.
```yaml
on:
create
```
## `delete`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`delete`](/de/webhooks/webhook-events-and-payloads#delete) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags auf einmal löschst.
Führt deinen Workflow aus, wenn ein Git-Verweis (Git-Verzweigung oder -Tag) im Repository des Workflows gelöscht wird. Informationen über die APIs zum Löschen einer Git-Referenz findest du unter [Git](/de/graphql/reference/git#mutation-deleteref) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Git-Verweise](/de/rest/git/refs#delete-a-reference).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `delete` eintritt.
```yaml
on:
delete
```
## `deployment`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | --------------- | ------------------------- | ------------------------------------------------------------------------------------------------ |
| [`deployment`](/de/webhooks/webhook-events-and-payloads#deployment) | Nicht verfügbar | Bereitzustellender Commit | Bereitzustellender Branch oder bereitzustellendes Tag (leer, wenn mit einem Commit-SHA erstellt) |
Führt deinen Workflow aus, wenn eine Bereitstellung im Repository des Workflows erstellt wird. Bereitstellungen, die mit einem Commit-SHA erstellt wurden, verfügen möglicherweise nicht über eine Git-Referenz. Informationen über die APIs zum Erstellen einer Bereitstellung findest du unter [Deployments](/de/graphql/reference/deployments#mutation-createdeployment) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Repositorys](/de/rest/repos#deployments).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `deployment` eintritt.
```yaml
on:
deployment
```
## `deployment_status`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------------------- | --------------- | ------------------------- | ---------------------------------------------------- |
| [`deployment_status`](/de/webhooks/webhook-events-and-payloads#deployment_status) | Nicht verfügbar | Bereitzustellender Commit | Bereitzustellender Branch oder Tag (leer bei Commit) |
> \[!NOTE]
> Wenn der Status einer Bereitstellung auf `inactive` festgelegt ist, wird keine Workflow-Ausführung ausgelöst.
Führt deinen Workflow aus, wenn ein Drittanbieter einen Bereitstellungsstatus bereitstellt. Bereitstellungen, die mit einem Commit-SHA erstellt wurden, haben möglicherweise keine Git-Referenz. Informationen über die APIs zum Erstellen eines Bereitstellungsstatus findest du unter [Deployments](/de/graphql/reference/deployments#mutation-createdeploymentstatus) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Bereitstellungen](/de/rest/deployments#create-a-deployment-status).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `deployment_status` eintritt.
```yaml
on:
deployment_status
```
## `discussion`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | -------------- |
| [`discussion`](/de/webhooks/webhook-events-and-payloads#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#discussion). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Webhookereignisse für GitHub Discussions sind derzeit als Öffentliche Vorschau verfügbar. Änderungen sind vorbehalten.
Führt deinen Workflow aus, wenn eine Diskussion im Repository des Workflows erstellt oder geändert wird. Für Aktivitäten, die sich auf Kommentare zu einer Diskussion beziehen, verwende das [`discussion_comment`](#discussion_comment)-Ereignis. Weitere Informationen über Diskussionen findest du unter [Informationen zu Diskussionen](/de/discussions/collaborating-with-your-community-using-discussions/about-discussions). Informationen über die GraphQL API findest du unter [Diskussionen](/de/graphql/reference/discussions#object-discussion).
Du kannst beispielsweise einen Workflow ausführen, wenn eine Diskussion erstellt (`created`), bearbeitet (`edited`) oder beantwortet (`answered`) wurde.
```yaml
on:
discussion:
types: [created, edited, answered]
```
## `discussion_comment`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------- | ----------------------------------------------- | -------------------------------- | -------------- |
| [`discussion_comment`](/de/webhooks/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#discussion_comment). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Webhookereignisse für GitHub Discussions sind derzeit als Öffentliche Vorschau verfügbar. Änderungen sind vorbehalten.
Führt deinen Workflow aus, wenn ein Kommentar zu einer Diskussion im Repository des Workflows erstellt oder geändert wird. Für Aktivitäten, die sich auf eine Diskussion beziehen, im Gegensatz zu Kommentaren zu einer Diskussion, verwende das [`discussion`](#discussion)-Ereignis. Weitere Informationen über Diskussionen findest du unter [Informationen zu Diskussionen](/de/discussions/collaborating-with-your-community-using-discussions/about-discussions). Informationen über die GraphQL API findest du unter [Diskussionen](/de/graphql/reference/discussions#object-discussion).
Du kannst beispielsweise einen Workflow ausführen, wenn ein Kommentar zu einer Diskussion erstellt (`created`) oder gelöscht (`deleted`) wurde.
```yaml
on:
discussion_comment:
types: [created, deleted]
```
## `fork`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`fork`](/de/webhooks/webhook-events-and-payloads#fork) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn jemand ein Repository forkt. Informationen über die REST-API findest du unter [REST-API-Endpunkte für forken](/de/rest/repos/forks#create-a-fork).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `fork` eintritt.
```yaml
on:
fork
```
## `gollum`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`gollum`](/de/webhooks/webhook-events-and-payloads#gollum) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn jemand eine Wiki-Seite erstellt oder aktualisiert. Weitere Informationen findest du unter [Informationen zu Wikis](/de/communities/documenting-your-project-with-wikis/about-wikis).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `gollum` eintritt.
```yaml
on:
gollum
```
## `image_version`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------- | --------------- | -------------------------------- | -------------- |
| Nicht verfügbar | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
Führt Ihren Workflow aus, wenn eine neue Version eines angegebenen Bilds zur Verwendung verfügbar wird. Dieses Ereignis wird in der Regel nach einer erfolgreichen Erstellung einer Imageversion ausgelöst, sodass Sie Aktionen wie bereitstellungs- oder Benachrichtigungen als Reaktion auf neue Imageversionen automatisieren können.
Dieses Ereignis unterstützt Glob-Patterns sowohl für Image-Namen als auch für Versionen. Das folgende Beispiel wird ausgelöst, wenn eine neue Bildversion mit einer der angegebenen Kombinationen aus Namen und Version übereinstimmt. Beispiel: `["MyNewImage", 1.0.0]`, , `["MyNewImage", 2.53.0]`, `["MyOtherImage", 1.0.0]`, und `["MyOtherImage", 2.0.0]`.
```yaml
on:
image_version:
names:
- "MyNewImage"
- "MyOtherImage"
versions:
- 1.*
- 2.*
```
## `issue_comment`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------- | ----------------------------------------------- | -------------------------------- | -------------- |
| [`issue_comment`](/de/webhooks/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#issue_comment). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn ein Issue oder ein Pull-Request-Kommentar erstellt, bearbeitet oder gelöscht wird. Informationen zu den Problem-Kommentar-APIs findest du unter [Probleme](/de/graphql/reference/issues#object-issuecomment) in der GraphQL API-Dokumentation oder [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#issue_comment) in der REST-API-Dokumentation.
Du kannst z. B. einen Workflow ausführen, wenn ein Issue oder ein Pull-Request-Kommentar erstellt (`created`) oder gelöscht (`deleted`) wurde.
```yaml
on:
issue_comment:
types: [created, deleted]
```
### `issue_comment` nur bei Problemen oder Pull-Requests
Das Ereignis `issue_comment` tritt für Kommentare zu Issues und Pull Requests auf. Du kannst die Eigenschaft `github.event.issue.pull_request` in einer Bedingung verwenden, um je nachdem, ob das auslösende Objekt ein Issue oder ein Pull Request war, unterschiedliche Aktionen auszuführen.
Dieser Workflow führt z. B. den Auftrag `pr_commented` nur aus, wenn das Ereignis `issue_comment` aus einem Pull Request stammt. Der Auftrag `issue_commented` wird nur ausgeführt, wenn das Ereignis `issue_comment` aus einem Issue stammt.
```yaml
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 A comment on PR $NUMBER
env:
NUMBER: ${{ 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 A comment on issue $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
```
## `issues`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | -------------- |
| [`issues`](/de/webhooks/webhook-events-and-payloads#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `typed`
- `untyped`
- `field_added`
- `field_removed` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#issues). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn ein Issue im Repository des Workflows erstellt oder geändert wird. Für Aktivitäten, die sich auf Kommentare in einem Problem beziehen, verwende das [`issue_comment`](#issue_comment)-Ereignis. Weitere Informationen zu Problemen findest du unter [Informationen zu Problemen](/de/issues/tracking-your-work-with-issues/learning-about-issues/about-issues). Informationen über die Problem-APIs findest du unter [Probleme](/de/graphql/reference/issues#object-issue) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Issues](/de/rest/issues).
Du kannst beispielsweise einen Workflow ausführen, wenn ein Issue geöffnet (`opened`), bearbeitet (`edited`) oder dafür ein Meilenstein erstellt wurde (`milestoned`).
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
Sie können einen Workflow auch ausführen, wenn ein Problemfeldwert festgelegt, geändert oder gelöscht wird. Der `field_added` Aktivitätstyp wird ausgelöst, wenn ein Feldwert anfangs festgelegt wird und ein vorhandener Wert aktualisiert wird. Der Aktivitätstyp `field_removed` wird ausgelöst, wenn ein Feldwert gelöscht wird.
```yaml
on:
issues:
types: [field_added, field_removed]
```
## `label`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------- | ----------------------------------------------- | -------------------------------- | -------------- |
| [`label`](/de/webhooks/webhook-events-and-payloads#label) | - `created`
- `edited`
- `deleted`
| Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#label). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn eine Bezeichnung im Repository des Workflows erstellt oder geändert wird. Weitere Informationen über Labels findest du unter [Verwalten von Labels](/de/issues/using-labels-and-milestones-to-track-work/managing-labels). Informationen über die Labels-APIs findest du unter [Probleme](/de/graphql/reference/issues#object-label) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Labels](/de/rest/issues/labels).
Wenn du deinen Workflow ausführen möchtest, wenn ein Label zu einem Problem, Pull-Request oder einer Diskussion hinzugefügt oder entfernt wird, verwende stattdessen die `labeled`- oder `unlabeled`-Aktivitätstypen für die [`issues`](#issues)-, [`pull_request`](#pull_request)-, [`pull_request_target`](#pull_request_target)- oder [`discussion`](#discussion)-Ereignisse.
Du kannst z. B. einen Workflow ausführen, wenn eine Bezeichnung erstellt (`created`) oder gelöscht (`deleted`) wurde.
```yaml
on:
label:
types: [created, deleted]
```
## `merge_group`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------- | ------------------ | ------------------- | ------------------- |
| [`merge_group`](/de/webhooks/webhook-events-and-payloads#merge_group) | `checks_requested` | SHA der Mergegruppe | Ref der Mergegruppe |
> \[!NOTE]
>
> *
Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der `checks_requested` Aktivitätstyp unterstützt wird, wird die Angabe des Aktivitätstyps Ihren Workflow spezifisch halten, wenn in Zukunft weitere Aktivitätstypen hinzugefügt werden. Informationen zu den einzelnen Aktivitätstypen findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#merge_group). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
> * Wenn Ihr Repository GitHub Actions verwendet, um erforderliche Prüfungen für Pull Requests in Ihrem Repository benötigen, müssen Sie die Workflows aktualisieren, um das `merge_group` Ereignis als zusätzlichen Auslöser einzubeziehen. Andernfalls werden Statusüberprüfungen nicht ausgelöst, wenn du einer Mergewarteschlange einen Pull Request hinzufügst. Der Merge ist nicht erfolgreich, da die erforderliche Statusüberprüfung nicht gemeldet wird. Das `merge_group`-Ereignis ist von den Ereignissen `pull_request` und `push` getrennt.
Führt deinen Workflow aus, wenn einer Mergewarteschlange ein Pull Request hinzugefügt wird, die den Pull Request wiederum einer Mergegruppe hinzufügt. Weitere Informationen findest du unter [Zusammenführen eines Pull Requests mit einer Merge-Warteschlange](/de/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue).
Du kannst beispielsweise einen Workflow ausführen, wenn die Aktivität `checks_requested` eingetreten ist.
```yaml
on:
pull_request:
branches: [ "main" ]
merge_group:
types: [checks_requested]
```
## `milestone`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------- | -------------- |
| [`milestone`](/de/webhooks/webhook-events-and-payloads#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#milestone). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn ein Meilenstein im Repository des Workflows erstellt oder geändert wird. Weitere Informationen zu Meilensteinen findest du unter [Informationen zu Meilensteinen](/de/issues/using-labels-and-milestones-to-track-work/about-milestones). Informationen über die Meilenstein-APIs findest du unter [Probleme](/de/graphql/reference/issues#object-milestone) in der GraphQLAPI-Dokumentation oder [REST-API-Endpunkte für Meilensteine](/de/rest/issues/milestones).
Wenn du deinen Workflow ausführen willst, wenn ein Problem zu einem Meilenstein hinzugefügt oder aus ihm entfernt wird, verwende stattdessen die `milestoned` oder `demilestoned` Aktivitätstypen für das [`issues`](#issues)-Ereignis.
Du kannst z. B. einen Workflow ausführen, wenn ein Meilenstein geöffnet (`opened`) oder gelöscht (`deleted`) wurde.
```yaml
on:
milestone:
types: [opened, deleted]
```
## `page_build`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`page_build`](/de/webhooks/webhook-events-and-payloads#page_build) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt Ihren Workflow aus, wenn jemand in eine Verzweigung überträgt, die als Veröffentlichungsquelle für GitHub Pages gilt, wenn GitHub Pages für das Repository aktiviert ist. Weitere Informationen zu GitHub Pages Veröffentlichungsquellen finden Sie unter [Eine Veröffentlichungsquelle für deine GitHub Pages-Website konfigurieren](/de/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site). Informationen über die REST-API findest du unter [REST-API-Endpunkte für Repositorys](/de/rest/repos#pages).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `page_build` eintritt.
```yaml
on:
page_build
```
## `public`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`public`](/de/webhooks/webhook-events-and-payloads#public) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn sich das Repository deines Workflows von privat in öffentlich ändert. Informationen über die REST-API findest du unter [REST-API-Endpunkte für Repositorys](/de/rest/repos#edit).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `public` eintritt.
```yaml
on:
public
```
## `pull_request`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | ---------------------------------------------------- |
| [`pull_request`](/de/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Letzter Merge-Commit im Branch `GITHUB_REF` | PR-Mergebranch `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#pull_request). Standardmäßig wird ein Workflow nur ausgeführt, wenn der Aktivitätstyp eines `pull_request`-Ereignisses `opened`, `synchronize` oder `reopened` ist. Verwende das Schlüsselwort `types`, um Workflows durch verschiedene Aktivitätstypen auszulösen. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Workflows werden nicht für `pull_request`-Aktivitäten ausgeführt, wenn der Pull Request einen Mergekonflikt aufweist. Der Mergekonflikt muss zuerst behoben werden. Umgekehrt werden Workflows mit dem Ereignis `pull_request_target` ausgeführt, auch wenn der Pull Request einen Mergekonflikt aufweist. Bevor du den Trigger `pull_request_target` verwendest, solltest du dich der Sicherheitsrisiken bewusst sein. Weitere Informationen findest du unter [`pull_request_target`](#pull_request_target).
> * Die `pull_request` Nutzlast des Webhook-Ereignisses ist bei zusammengeführten Pull Requests und Pull Requests, die aus geforkten Repositorys stammen, leer.
> * Wenn ein Pull Request von einem Workflow unter Verwendung von `GITHUB_TOKEN`- und `pull_request`-Ereignissen mit den Aktivitätstypen `opened`, `synchronize` oder `reopened` erstellt oder aktualisiert wird, werden Workflowausführungen erstellt, die eine Genehmigung erfordern. Ein Benutzer mit Schreibzugriff auf das Repository kann diese Ausführung über die Pullanforderungsseite genehmigen. Mit Ausnahme von `workflow_dispatch` und `repository_dispatch` erzeugen andere `GITHUB_TOKEN`-ausgelöste Ereignisse überhaupt keine Workflow-Ausführungen.
> * Der Wert `GITHUB_REF` variiert für eine geschlossene Pullanforderung, je nachdem, ob die Pullanforderung zusammengeführt wurde oder nicht. Wenn eine Pullanforderung geschlossen, aber nicht zusammengeführt wurde, lautet sie `refs/pull/PULL_REQUEST_NUMBER/merge`. Wenn eine Pullanforderung als Ergebnis der Zusammenführung geschlossen wurde, ist sie die vollqualifizierte `ref` der Verzweigung, mit der sie zusammengeführt wurde, z. B. `/refs/heads/main`.
Führt deinen Workflow aus, wenn Aktivitäten für einen Pull Request im Repository des Workflows stattfinden. Wenn beispielsweise keine Aktivitätstypen angegeben werden, wird der Workflow ausgeführt, wenn ein Pull Request geöffnet oder erneut geöffnet wird oder wenn der Headbranch des Pull Requests aktualisiert wird. Für Aktivitäten, die sich auf Pull-Reviews, Pull-Review-Kommentare oder Pull-Request-Kommentare beziehen, verwende stattdessen die [`pull_request_review`](#pull_request_review)-, [`pull_request_review_comment`](#pull_request_review_comment)- oder [`issue_comment`](#issue_comment)-Ereignisse. Informationen über die Pull-Request-APIs findest du unter [Pull-Anfragen](/de/graphql/reference/pulls#object-pullrequest) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Pullanforderungen](/de/rest/pulls).
Beachte, dass `GITHUB_SHA` für dieses Ereignis der letzte Merge-Commit des Pull-Request-Mergebranch ist. Wenn du die Commit-ID für den letzten Commit auf den Headbranch des Pull Requests abrufen möchtest, verwende stattdessen `github.event.pull_request.head.sha`. Weitere Informationen zu Merge-Zweigen finden Sie unter [Pull-Anfragen](/de/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches).
### Wie der Zusammenführungszweig Ihren Workflow beeinflusst
Bei offenen, zusammenführbaren Pull-Anfragen werden Workflows, die durch das `pull_request`-Ereignis ausgelöst werden, auf die Merge-Verzweigung `GITHUB_REF` festgelegt. Da `actions/checkout` standardmäßig `GITHUB_REF` verwendet wird, checkt es die Merge-Verzweigung aus. Ihre CI-Tests werden mit dem zusammengeführten Ergebnis ausgeführt, nicht nur die Head-Verzweigung allein:
* `GITHUB_REF` ist auf `refs/pull/PULL_REQUEST_NUMBER/merge` festgelegt.
* `GITHUB_SHA` ist der SHA des Merge-Commits auf der Merge-Verzweigung.
Um nur die Commits der Head-Verzweigung zu testen, ohne eine Zusammenführung zu simulieren, verwenden Sie im Workflow `github.event.pull_request.head.sha`.
Du kannst beispielsweise einen Workflow ausführen, wenn ein Pull Request geöffnet oder erneut geöffnet wurde.
```yaml
on:
pull_request:
types: [opened, reopened]
```
Du kannst den Ereigniskontext verwenden, um die Ausführung von Aufträgen in deinem Workflow weiter zu steuern. Dieser Workflow wird beispielsweise ausgeführt, wenn eine Überprüfung für einen Pull Request angefordert wird, der Auftrag `specific_review_requested` jedoch nur ausgeführt wird, wenn eine Überprüfung von `octo-team` angefordert wird.
```yaml
on:
pull_request:
types: [review_requested]
jobs:
specific_review_requested:
runs-on: ubuntu-latest
if: ${{ github.event.requested_team.name == 'octo-team'}}
steps:
- run: echo 'A review from octo-team was requested'
```
### Ausführen des `pull_request`-Workflows basierend auf dem Head- oder Basisbranch eines Pull Requests
Du kannst den Workflow mithilfe des Filters `branches` oder `branches-ignore` so konfigurieren, dass er nur für Pull Requests ausgeführt wird, die auf bestimmte Branches abzielen. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore).
Dieser Workflow wird beispielsweise ausgeführt, wenn jemand einen Pull Request öffnet, der auf einen Branch abzielt, dessen Name mit `releases/` beginnt:
```yaml
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> Wenn du sowohl den `branches`-Filter als auch den `paths`-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull-Request, der eine Änderung an einer JavaScript-Datei (`.js`) enthält, in einem Branch geöffnet wird, dessen Name mit `releases/` beginnt:
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
Zur Ausführung eines Auftrags basierend auf dem Headbranchnamen des Pull Requests (im Gegensatz zum Basisbranchnamen des Pull Requests) verwende den `github.head_ref`-Kontext in einer Bedingung. Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request geöffnet wird, aber der Auftrag `run_if` wird nur ausgeführt, wenn der Kopfteil des Pull Requests ein Branch ist, dessen Name mit `releases/` beginnt:
```yaml
on:
pull_request:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### Ausführen des `pull_request`-Workflows basierend auf Dateien, die in einem Pull Request geändert wurden
Du kannst deinen Workflow auch so konfigurieren, dass er ausgeführt wird, wenn ein Pull Request bestimmte Dateien ändert. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request eine Änderung an einer JavaScript-Datei (`.js`) enthält:
```yaml
on:
pull_request:
paths:
- '**.js'
```
> \[!NOTE]
> Wenn du sowohl den `branches`-Filter als auch den `paths`-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull-Request, der eine Änderung an einer JavaScript-Datei (`.js`) enthält, in einem Branch geöffnet wird, dessen Name mit `releases/` beginnt:
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### Ausführen des `pull_request`-Workflows beim Zusammenführen eines Pull Requests
Beim Zusammenführen eines Pull Requests wird der Pull Request automatisch geschlossen. Um einen Workflow auszuführen, wenn eine Pull-Request zusammengeführt wird, verwende den Ereignistyp `pull_request``closed` zusammen mit einer Bedingung, die den `merged`-Wert des Ereignisses überprüft. Der folgende Workflow wird beispielsweise ausgeführt, wenn ein Pull Request geschlossen wird. Der Auftrag `if_merged` wird nur ausgeführt, wenn der Pull Request auch zusammengeführt wurde.
```yaml
on:
pull_request:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
#### Workflows in geforkten Repositorys
Workflows werden standardmäßig nicht in geforkten Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte **Aktionen** des geforkten Repositorys aktivieren.
Mit Ausnahme von `GITHUB_TOKEN` werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. Das `GITHUB_TOKEN` verfügt in Pull Requests aus geforkten Repositorys über schreibgeschützte Berechtigungen. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/actions/security-guides/automatic-token-authentication).
#### Pull-Request-Ereignisse für geforkte Repositorys
Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub die Ereignisse `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review` und `pull_request_target` an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.
Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen finden Sie unter [Genehmigen von Workflowausführungen über Forks](/de/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unter[Einstellung der GitHub Actions für ein Repository verwalten](/de/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.
## `pull_request_comment` (verwende `issue_comment`)
Um deinen Workflow auszuführen, wenn ein Kommentar zu einer Pull-Request (nicht zum Diff einer Pull-Request) erstellt, bearbeitet oder gelöscht wird, verwende das [`issue_comment`](#issue_comment)-Ereignis. Für Aktivitäten, die sich auf Pull-Reviews oder Kommentare zu Pull-Reviews beziehen, verwendest du die [`pull_request_review`](#pull_request_review)- oder [`pull_request_review_comment`](#pull_request_review_comment)-Ereignisse.
## `pull_request_review`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------- | ---------------------------------------------------- |
| [`pull_request_review`](/de/webhooks/webhook-events-and-payloads#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | Letzter Merge-Commit im Branch `GITHUB_REF` | PR-Mergebranch `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#pull_request_review). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Führt deinen Workflow aus, wenn eine Pull-Request-Überprüfung übermittelt, bearbeitet oder geschlossen wird. Eine Pull-Request-Überprüfung ist eine Gruppe von Pull-Request-Überprüfungskommentaren zusätzlich zu einem Textkörperkommentar und einem Zustand. Für Aktivitäten, die sich auf Pull-Request-Review-Kommentare oder Pull-Request-Kommentare beziehen, verwende stattdessen die [`pull_request_review_comment`](#pull_request_review_comment)- oder [`issue_comment`](#issue_comment)-Ereignisse. Informationen zu den Pull-Request-Review-APIs findest du unter [Pull-Anfragen](/de/graphql/reference/pulls#object-pullrequest) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Pullanforderungen](/de/rest/pulls#reviews).
Du kannst beispielsweise einen Workflow ausführen, wenn ein Pull Request bearbeitet (`edited`) oder geschlossen (`dismissed`) wurde.
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
### Ausführen eines Workflows, wenn ein Pull Request genehmigt wurde
Für die Ausführung deines Workflows, wenn ein Pull Request genehmigt wurde, kannst du deinen Workflow mit dem Typ `submitted` des Ereignisses `pull_request_review` auslösen und dann den Überprüfungsstatus mit der `github.event.review.state`-Eigenschaft überprüfen. Dieser Workflow wird beispielsweise ausgeführt, wenn eine Pull-Request-Überprüfung übermittelt wird, der `approved`-Auftrag jedoch nur ausgeführt wird, wenn die übermittelte Überprüfung eine Genehmigungsüberprüfung ist:
```yaml
on:
pull_request_review:
types: [submitted]
jobs:
approved:
if: github.event.review.state == 'approved'
runs-on: ubuntu-latest
steps:
- run: echo "This PR was approved"
```
#### Workflows in geforkten Repositorys
Workflows werden standardmäßig nicht in geforkten Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte **Aktionen** des geforkten Repositorys aktivieren.
Mit Ausnahme von `GITHUB_TOKEN` werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. Das `GITHUB_TOKEN` verfügt in Pull Requests aus geforkten Repositorys über schreibgeschützte Berechtigungen. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/actions/security-guides/automatic-token-authentication).
#### Pull-Request-Ereignisse für geforkte Repositorys
Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub die Ereignisse `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review` und `pull_request_target` an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.
Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen finden Sie unter [Genehmigen von Workflowausführungen über Forks](/de/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unter[Einstellung der GitHub Actions für ein Repository verwalten](/de/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.
## `pull_request_review_comment`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------- | ---------------------------------------------------- |
| [`pull_request_review_comment`](/de/webhooks/webhook-events-and-payloads#pull_request_review_comment) | - `created`
- `edited`
- `deleted` | Letzter Merge-Commit im Branch `GITHUB_REF` | PR-Mergebranch `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#pull_request_review_comment). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Führt deinen Workflow aus, wenn ein Pull-Request-Überprüfungskommentar geändert wird. Ein Pull-Request-Überprüfungskommentar ist ein Kommentar zu einem Pull-Request-Diff. Für Aktivitäten im Zusammenhang mit Pull-Review- oder Pull-Request Kommentaren, verwende stattdessen die [`pull_request_review`](#pull_request_review)- oder [`issue_comment`](#issue_comment)-Ereignisse. Informationen zu den Pull-Request-Kommentar-APIs findest du unter [Pull-Anfragen](/de/graphql/reference/pulls#object-pullrequestreviewcomment) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Pullanforderungen](/de/rest/pulls#comments).
Du kannst beispielsweise einen Workflow ausführen, wenn ein Pull-Request-Überprüfungskommentar erstellt (`created`) oder gelöscht (`deleted`) wurde.
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
#### Workflows in geforkten Repositorys
Workflows werden standardmäßig nicht in geforkten Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte **Aktionen** des geforkten Repositorys aktivieren.
Mit Ausnahme von `GITHUB_TOKEN` werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. Das `GITHUB_TOKEN` verfügt in Pull Requests aus geforkten Repositorys über schreibgeschützte Berechtigungen. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/actions/security-guides/automatic-token-authentication).
#### Pull-Request-Ereignisse für geforkte Repositorys
Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub die Ereignisse `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review` und `pull_request_target` an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.
Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen finden Sie unter [Genehmigen von Workflowausführungen über Forks](/de/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unter[Einstellung der GitHub Actions für ein Repository verwalten](/de/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.
## `pull_request_target`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | -------------- |
| | | | |
| [`pull_request`](/de/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Letzter Commit an Default-Branch | Default-Branch |
| | | | |
> \[!NOTE]
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#pull_request). Standardmäßig wird ein Workflow nur ausgeführt, wenn der Aktivitätstyp eines `pull_request_target`-Ereignisses `opened`, `synchronize` oder `reopened` ist. Verwende das Schlüsselwort `types`, um Workflows durch verschiedene Aktivitätstypen auszulösen. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Führt deinen Workflow aus, wenn Aktivitäten für einen Pull Request im Repository des Workflows stattfinden. Wenn beispielsweise keine Aktivitätstypen angegeben werden, wird der Workflow ausgeführt, wenn ein Pull Request geöffnet oder erneut geöffnet wird oder wenn der Headbranch des Pull Requests aktualisiert wird.
Dieses Ereignis wird im Kontext der des Basis-Repositorys statt im Kontext des Zusammenführungs-Commits ausgeführt, wie das `pull_request` Ereignis tut. Dadurch wird verhindert, dass unsicherer Code vom Kopfteil des Pull Requests ausgeführt wird, der dein Repository ändern oder Geheimnisse stehlen könnte, die du in deinem Workflow verwendest. Dieses Ereignis ermöglicht es deinem Workflow, Aufgaben wie das Kennzeichnen oder Kommentieren von Pull Requests von Forks auszuführen. Vermeide die Verwendung dieses Ereignisses, wenn du Code aus dem Pull Request erstellen oder ausführen musst.
Um die Repositorysicherheit sicherzustellen, lösen Branches mit Namen, die bestimmten Mustern entsprechen (z. B. solche, die SHAs ähneln), möglicherweise keine Workflows mit dem `pull_request_target`-Ereignis aus.
> \[!WARNING]
> Das Ausführen nicht vertrauenswürdigen Codes beim Trigger `pull_request_target` kann zu Sicherheitsrisiken führen. Zu diesen Sicherheitsrisiken gehören Cachepoisoning und das Gewähren unbeabsichtigten Zugriffs auf Schreibberechtigungen oder Geheimnisse. Informationen zur sicheren Verwendung dieses Triggers finden Sie unter [Sichere Verwendung von pull\_request\_target](/de/actions/reference/security/securely-using-pull_request_target). Weitere Informationen zu den zugrunde liegenden Risiken finden Sie in [Referenz zur sicheren Verwendung](/de/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) und [Verhindern kompromittierter Anfragen](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) von GitHub Security Lab.
Du kannst beispielsweise einen Workflow ausführen, wenn ein Pull Request zugewiesen (`assigned`), geöffnet (`opened`), synchronisiert (`synchronize`) oder erneut geöffnet (`reopened`) wurde.
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### Ausführen des `pull_request_target`-Workflows basierend auf dem Head- oder Basisbranch eines Pull Requests
Du kannst den Workflow mithilfe des Filters `branches` oder `branches-ignore` so konfigurieren, dass er nur für Pull Requests ausgeführt wird, die auf bestimmte Branches abzielen. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore).
Dieser Workflow wird beispielsweise ausgeführt, wenn jemand einen Pull Request öffnet, der auf einen Branch abzielt, dessen Name mit `releases/` beginnt:
```yaml
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> Wenn du sowohl den `branches`-Filter als auch den `paths`-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull-Request, der eine Änderung an einer JavaScript-Datei (`.js`) enthält, in einem Branch geöffnet wird, dessen Name mit `releases/` beginnt:
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
Zur Ausführung eines Auftrags basierend auf dem Headbranchnamen des Pull Requests (im Gegensatz zum Basisbranchnamen des Pull Requests) verwende den `github.head_ref`-Kontext in einer Bedingung. Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request geöffnet wird, aber der Auftrag `run_if` wird nur ausgeführt, wenn der Kopfteil des Pull Requests ein Branch ist, dessen Name mit `releases/` beginnt:
```yaml
on:
pull_request_target:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### Ausführen des `pull_request_target`-Workflows basierend auf Dateien, die in einem Pull Request geändert wurden
Du kannst den Filter `paths` oder `paths-ignore` verwenden, um deinen Workflow so zu konfigurieren, dass er ausgeführt wird, wenn ein Pull Request bestimmte Dateien ändert. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request eine Änderung an einer JavaScript-Datei (`.js`) enthält:
```yaml
on:
pull_request_target:
paths:
- '**.js'
```
> \[!NOTE]
> Wenn du sowohl den `branches`-Filter als auch den `paths`-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull-Request, der eine Änderung an einer JavaScript-Datei (`.js`) enthält, in einem Branch geöffnet wird, dessen Name mit `releases/` beginnt:
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### Ausführen des `pull_request_target`-Workflows beim Zusammenführen eines Pull Requests
Beim Zusammenführen eines Pull Requests wird der Pull Request automatisch geschlossen. Um einen Workflow auszuführen, wenn eine Pull-Request zusammengeführt wird, verwende den Ereignistyp `pull_request_target``closed` zusammen mit einer Bedingung, die den `merged`-Wert des Ereignisses überprüft. Der folgende Workflow wird beispielsweise ausgeführt, wenn ein Pull Request geschlossen wird. Der Auftrag `if_merged` wird nur ausgeführt, wenn der Pull Request auch zusammengeführt wurde.
```yaml
on:
pull_request_target:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
## `push`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| [`push`](/de/webhooks/webhook-events-and-payloads#push) | Nicht verfügbar | Commit-Pushes zum Ref. Wenn du einen Branch löschst, wird der SHA des ausgeführten Workflows (und die zugehörigen Refs) auf den Default-Branch des Repositorys zurückgesetzt. | Aktualisierter Ref |
> \[!NOTE]
>
> * Die für GitHub Actions verfügbare Webhook-Nutzlast enthält nicht die Attribute `added`, `removed` und `modified` im objekt `commit`. Du kannst das vollständige Commitobjekt mithilfe der API abrufen. Weitere Informationen findest du unter [Commits](/de/graphql/reference/commits#object-commit) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Commits](/de/rest/commits#get-a-commit).
> * Ereignisse werden nicht erstellt, wenn mehr als 5.000 Branches auf einmal übertragen werden. Hinweis: Ein Ereignis wird nicht erstellt, wenn Sie mehr als drei Tags gleichzeitig pushen.
Führt den Workflow aus, wenn ein Commit oder Tag übertragen oder ein Repository geklont wird. Dazu gehören Workflows, die nicht mit der Standardverzweigung zusammengeführt werden. Weitere Informationen findest du unter [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-workflow-only-when-a-push-to-specific-branches-occurs).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `push` eintritt.
```yaml
on:
push
```
> \[!NOTE]
> Wenn ein `push`-Webhook-Ereignis einen Workflow-Ausführung auslöst, wird im Feld „pushed by“ der Actions-Benutzeroberfläche das Konto des Pushers angezeigt und nicht der Autor oder Committer. Wenn die Änderungen jedoch mit einer SSH-Authentifizierung mit einem Bereitstellungsschlüssel an ein Repository gepusht werden, entspricht das Feld „Push durch“ dem bzw. der Repositoryadministrator\*in, der bzw. die den Bereitstellungsschlüssel überprüft hat, als dieser einem Repository hinzugefügt wurde.
### Ausführen des Workflows nur, wenn ein Push an bestimmte Branches stattfindet
Du kannst den Workflow mithilfe des Filters `branches` oder `branches-ignore` so konfigurieren, dass er nur ausgeführt wird, wenn bestimmte Branches gepusht werden. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore).
Dieser Workflow wird z. B. ausgeführt, wenn ein Push an `main` oder an einen Branch stattfindet, der mit `releases/` beginnt.
```yaml
on:
push:
branches:
- 'main'
- 'releases/**'
```
> \[!NOTE]
> Wenn du sowohl den `branches`-Filter als auch den `paths`-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Push, der eine Änderung an einer JavaScript-Datei (`.js`) enthält, an einer Verzweigung vorgenommen wird, deren Name beginnt mit `releases/`:
>
> ```yaml
> on:
> push:
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### Ausführen des Workflows nur dann, wenn ein Push von bestimmten Tags stattfindet
Du kannst den Workflow mithilfe des Filters `tags` oder `tags-ignore` so konfigurieren, dass er nur ausgeführt wird, wenn bestimmte Tags gepusht werden. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore).
Dieser Workflow wird z. B. ausgeführt, wenn ein Tag gepusht wird, das mit `v1.` beginnt.
```yaml
on:
push:
tags:
- v1.**
```
### Ausführen deines Workflows nur dann, wenn ein Push bestimmte Dateien betrifft
Du kannst den Filter `paths` oder `paths-ignore` verwenden, um deinen Workflow so konfigurieren, dass er ausgeführt wird, wenn ein Push an bestimmte Dateien stattfindet. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Dieser Workflow wird beispielsweise ausgeführt, wenn eine Änderung an eine JavaScript-Datei (`.js`) gepusht wird:
```yaml
on:
push:
paths:
- '**.js'
```
## `registry_package`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------- | ----------------------------- | ---------------------------------- | ------------------------------------------- |
| [`registry_package`](/de/webhooks/webhook-events-and-payloads#package) | - `published`
- `updated` | Commit des veröffentlichten Pakets | Branch oder Tag des veröffentlichten Pakets |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#registry_package). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Beim Pushing von Multi-Architektur Container-Images tritt dieses Ereignis einmal pro Manifest auf, sodass dein Workflow unter Umständen mehrfach getriggert wird. Verwende eine Bedingung, um dieses Phänomen zu minimieren und den Workflowauftrag nur für das Ereignis auszuführen, das die tatsächlichen Imagetaginformationen enthält:
>
> ```yaml
> jobs:
> job_name:
> if: $true
> ```
Führt Ihren Workflow aus, wenn in Ihrem Repository eine Aktivität im Zusammenhang mit GitHub Packages auftritt. Weitere Informationen finden Sie in [GitHub Packages der Dokumentation](/de/packages).
Du kannst z. B. einen Workflow ausführen, wenn eine neue Paketversion veröffentlicht (`published`) wurde.
```yaml
on:
registry_package:
types: [published]
```
## `release`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------ |
| [`release`](/de/webhooks/webhook-events-and-payloads#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | Letzter Commit in dem bezeichneten Release | Tag-Ref des Release `refs/tags/` |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#release). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Workflows werden nicht für die `created`, `edited` oder `deleted` Aktivitätstypen für Versionsentwürfe ausgelöst. Wenn Sie Ihr Release über die GitHub Benutzeroberfläche erstellen, wird es möglicherweise automatisch als Entwurf gespeichert.
> * Der `prereleased`-Typ wird nicht für Vorabveröffentlichungen ausgelöst, die aus Veröffentlichungsentwürfen veröffentlicht werden, aber der `published`-Typ wird ausgelöst. Wenn ein Workflow ausgeführt werden soll, wenn stabile *- und*-Vorab-Releases veröffentlicht werden, abonniere `published` anstelle von `released` und `prereleased`.
Führt deinen Workflow aus, wenn die Freigabeaktivität in deinem Repository stattfindet. Informationen über die Veröffentlichungs-APIs findest du unter [Veröffentlichungen](/de/graphql/reference/releases#object-release) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Releases und Releaseressourcen](/de/rest/releases) in der REST-API-Dokumentation.
Du kannst z. B. einen Workflow ausführen, wenn ein Release veröffentlicht (`published`) wurde.
```yaml
on:
release:
types: [published]
```
## `repository_dispatch`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------ | ----------------- | -------------------------------- | -------------- |
| [repository\_dispatch](/de/webhooks/webhook-events-and-payloads#repository_dispatch) | Benutzerdefiniert | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Sie können die GitHub-API verwenden, um ein Webhook-Ereignis mit dem Namen [`repository_dispatch`](/de/webhooks/webhook-events-and-payloads#repository_dispatch) auszulösen, um einen Workflow für Aktivitäten auszulösen, die außerhalb von GitHub stattfinden. Weitere Informationen findest du unter [REST-API-Endpunkte für Repositorys](/de/rest/repos/repos#create-a-repository-dispatch-event).
Wenn du eine Anforderung zum Erstellen eines `repository_dispatch`-Ereignisses vornimmst, musst du einen `event_type` angeben, um den Aktivitätstyp zu beschreiben. Standardmäßig lösen alle `repository_dispatch`-Aktivitätstypen einen Workflow zum Ausführen aus. Du kannst das Schlüsselwort `types` verwenden, damit der Workflow nur ausgeführt wird, wenn ein bestimmter `event_type`-Wert im Webhook-Payload `repository_dispatch` gesendet wird.
```yaml
on:
repository_dispatch:
types: [test_result]
```
> \[!NOTE]
> Der `event_type`-Wert ist auf 100 Zeichen begrenzt.
Alle Daten, die du über den Parameter `client_payload` sendest, stehen im `github.event`-Kontext in deinem Workflow zur Verfügung. Wenn du beispielsweise diesen Anforderungstext sendest, wenn du ein Repository-Versandereignis erstellst:
```json
{
"event_type": "test_result",
"client_payload": {
"passed": false,
"message": "Error: timeout"
}
}
```
kannst du auf den Payload in einem Workflow wie folgt zugreifen:
```yaml
on:
repository_dispatch:
types: [test_result]
jobs:
run_if_failure:
if: ${{ !github.event.client_payload.passed }}
runs-on: ubuntu-latest
steps:
- env:
MESSAGE: ${{ github.event.client_payload.message }}
run: echo $MESSAGE
```
> \[!NOTE]
>
> * Die maximale Anzahl von Eigenschaften auf oberster Ebene in `client_payload` beträgt 10.
> * Die Nutzdaten dürfen maximal 65.535 Zeichen enthalten.
## `schedule`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------- | --------------- | -------------------------------- | -------------- |
| Nicht verfügbar | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
>
> * Das Ereignis `schedule` kann sich in Phasen mit einer hohen Auslastung durch GitHub Actions-Workflowausführungen verzögern. Eine hohe Last ist unter anderem zu Beginn jeder Stunde zu verzeichnen. Wenn die Auslastung ausreichend hoch ist, werden einige Aufträge in der Warteschlange möglicherweise gelöscht. Um die Wahrscheinlichkeit einer Verzögerung zu verringern, kannst du deinen Workflow so planen, dass er zu einer anderen Uhrzeit ausgeführt wird.
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Geplante Workflows werden nur auf dem Default-Branch ausgeführt.
> * In einem öffentlichen Repository werden geplante Workflows automatisch deaktiviert, wenn in 60 Tagen keine Repositoryaktivität aufgetreten ist. Weitere Informationen zu erneuten Aktivieren eines deaktivierten Workflows findest du unter [Deaktivieren und Aktivieren eines Workflows](/de/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows#enabling-a-workflow).
Mit dem `schedule`-Ereignis kannst du einen Workflow zu einem geplanten Zeitpunkt auslösen.
**Beispiel:**
```yaml
on:
schedule:
- cron: "15 4,5 * * *"
```
Verwenden Sie [POSIX-Cronsyntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) , um Workflows für die Ausführung zu bestimmten Zeiten zu planen. Standardmäßig werden geplante Workflows in UTC ausgeführt. Sie können optional eine Zeitzone mithilfe einer [IANA-Zeitzonenzeichenfolge](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) für die zeitzonenbewusste Planung angeben. Geplante Workflows werden für den letzten Commit auf dem Standard-Branch ausgeführt. Das kürzeste Intervall, in dem Du geplante Workflows ausführen kannst, ist einmal alle 5 Minuten.
> \[!NOTE]
> Für Zeitpläne, die auf eine Zeitzone `timezone` festgelegt sind, die die Sommerzeit (DST) berücksichtigt, werden während der Umstellung auf Sommerzeit im Frühjahr geplante Workflows in übersprungenen Stunden auf die nächste gültige Zeit vorgezogen. Ein Zeitplan von 2:30 Uhr wird z. B. auf 3:00 Uhr vorverschoben.
Die Cron-Syntax umfasst fünf durch Leerzeichen getrennte Felder, die jeweils eine Zeiteinheit darstellen.
```text
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *
```
Sie können diese Operatoren in jedem der fünf Felder verwenden.
| Operator | Beschreibung | Beispiel |
| -------------------------------------------------------------------------------------------------------- | ------------------------ | -------- |
| \* | Beliebiger Wert | |
| `15 * * * *` wird in jeder 15. Minute jeder Stunde jedes Tages ausgeführt. | | |
| , | Wertelisten-Trennzeichen | |
| `2,10 4,5 * * *` wird in der 2. und 10. Minute der 4. und 5. Stunde jedes Tages ausgeführt. | | |
| - | Wertebereich | |
| `30 4-6 * * *` läuft in der 30. Minute der 4., 5. und 6. Stunde. | | |
| / | Schrittwerte | |
| `20/15 * * * *` wird alle 15 Minuten ab der 20. bis zur 59. Minute ausgeführt (20., 35. und 50. Minute). | | |
In diesem Beispiel wird der Workflow so ausgelöst, dass er jeden Montag bis Freitag um 5:30 Uhr in der Zeitzone "Amerika/New\_York" ausgeführt wird:
```yaml
on:
schedule:
- cron: '30 5 * * 1-5'
timezone: "America/New_York"
```
Ein einzelner Workflow kann durch mehrere `schedule`-Ereignisse ausgelöst werden. Greife über den Kontext `schedule` auf das `github.event.schedule`-Ereignis zu, das den Workflow ausgelöst hat. In diesem Beispiel wird der Workflow so ausgelöst, dass er jeden Montag bis Donnerstag um 5:30 UTC und am Dienstag und Donnerstag um 17:30 UTC ausgeführt wird, überspringt jedoch Schritt `Not on Monday or Wednesday` am Montag und Mittwoch.
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5,17 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
> \[!NOTE]
> GitHub Actions unterstützt die nicht standardmäßige Syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly` und `@reboot` nicht.
Du kannst [Crontab-Guru](https://crontab.guru/) verwenden, um deine Cronsyntax zu generieren und zu bestätigen, zu welcher Zeit sie ausgeführt wird. Als Einstiegshilfe steht eine Liste mit [Crontab-Guru-Beispielen](https://crontab.guru/examples.html) bereit.
### `actor` für geplante Workflows
Bestimmte Repositoryereignisse ändern den dem Workflow zugeordneten `actor`. Beispielsweise wird ein Benutzer, der den Default-Branch des Repositorys ändert, was den Branch ändert, auf dem geplante Workflows ausgeführt werden, für diese geplanten Workflows der `actor`.
Wenn ein Benutzer mit `write`-Berechtigungen für das Repository bei einem deaktivierten geplanten Workflow einen Commit erstellt, der den `cron`-Zeitplan für den Workflow ändert, wird der Workflow erneut aktiviert, und dieser Benutzer wird zum `actor`-Element, das einer beliebigen Workflowausführung zugeordnet ist.
Benachrichtigungen für geplante Workflows werden an den Benutzer gesendet, der die Cronsyntax in der Workflowdatei zuletzt geändert hat. Weitere Informationen findest du unter [Benachrichtigungen für Workflow-Läufe](/de/actions/concepts/workflows-and-actions/notifications-for-workflow-runs).
> \[!NOTE]
> Für ein Unternehmen mit Enterprise Managed Users, das einen geplanten Workflow auslöst, muss der Status des `actor` Benutzerkontos, das dem Workflow zugeordnet ist, aktuell aktiv sein (d. h. nicht angehalten oder gelöscht).
>
> * Geplante Workflows werden nicht ausgeführt, wenn der letzte `actor`, der dem geplanten Workflow zugeordnet ist, vom Enterprise Managed User Identitätsanbieter (IdP) zurückgezogen wurde. Wenn der letzte `actor`Enterprise Managed User jedoch nicht aus der Bereitstellung durch den IdP entfernt wurde und nur als Mitglied einer bestimmten Organisation im Unternehmen entfernt wurde, werden geplante Workflows weiterhin ausgeführt, wobei dieser Benutzer als `actor` festgelegt ist.
> * Ebenso wird durch das Entfernen eines Benutzers aus einer Organisation in einem Unternehmen ohne Enterprise Managed Users nicht verhindert, dass geplante Workflows, bei denen dieser Benutzer als `actor` fungierte, weiterhin ausgeführt werden.
> * Daher ist sowohl der Status des *Benutzerkontos* in Enterprise Managed User- als auch in Nicht-Enterprise Managed User-Szenarien wichtig, *nicht* der *Mitgliedschaftsstatus* des Benutzers in der Organisation, in der sich der geplante Workflow befindet.
## `status`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`status`](/de/webhooks/webhook-events-and-payloads#status) | Nicht verfügbar | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn sich der Status eines Git-Commits ändert. Beispielsweise können Commits als `error`, `failure`, `pending` oder `success` gekennzeichnet werden. Wenn du mehr Details über die Statusänderung angeben möchtest, kannst du das [`check_run`](#check_run)-Ereignis verwenden. Informationen über die Commit-Status-APIs findest du unter [Commits](/de/graphql/reference/commits#object-status) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte für Commits](/de/rest/commits#commit-statuses).
Du kannst beispielsweise einen Workflow ausführen, wenn das Ereignis `status` eintritt.
```yaml
on:
status
```
Wenn du einen Auftrag in deinem Workflow basierend auf dem neuen Commitstatus ausführen möchtest, kannst du den `github.event.state`-Kontext verwenden. Der folgende Workflow löst z. B. aus, wenn sich ein Commitstatus ändert, aber der Auftrag `if_error_or_failure` wird nur ausgeführt, wenn der neue Commitstatus `error` oder `failure` ist.
```yaml
on:
status
jobs:
if_error_or_failure:
runs-on: ubuntu-latest
if: >-
github.event.state == 'error' ||
github.event.state == 'failure'
steps:
- env:
DESCRIPTION: ${{ github.event.description }}
run: |
echo The status is error or failed: $DESCRIPTION
```
## `watch`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------- | --------------- | -------------------------------- | -------------- |
| [`watch`](/de/webhooks/webhook-events-and-payloads#watch) | - `started` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der `started` Aktivitätstyp unterstützt wird, wird die Angabe des Aktivitätstyps Ihren Workflow spezifisch halten, wenn in Zukunft weitere Aktivitätstypen hinzugefügt werden. Informationen zu den einzelnen Aktivitätstypen findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#watch). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Führt deinen Workflow aus, wenn das Repository des Workflows markiert ist. Informationen über die Pull-Request-APIs findest du unter [Activity](/de/graphql/reference/activity#mutation-addstar) in der GraphQL API-Dokumentation oder [REST-API-Endpunkte zum Versehen mit einem Stern](/de/rest/activity/starring).
Du kannst z. B. einen Workflow ausführen, wenn ein Repository mit einem Stern markiert wird, wobei es sich um den Aktivitätstyp `started` für ein Überwachungsereignis handelt.
```yaml
on:
watch:
types: [started]
```
## `workflow_call`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------- | --------------- | ---------------------------------- | ---------------------------------- |
| Identisch mit dem Aufruferworkflow | Nicht verfügbar | Identisch mit dem Aufruferworkflow | Identisch mit dem Aufruferworkflow |
`workflow_call` wird verwendet, um anzuzeigen, dass ein Workflow von einem anderen Workflow aufgerufen werden kann. Wenn ein Workflow mit dem `workflow_call`-Ereignis ausgelöst wird, ist der Ereignis-Payload im aufgerufenen Workflow derselbe Ereignis-Payload wie aus dem aufrufenden Workflow. Weitere Informationen findest du unter [Wiederverwenden von Workflows](/de/actions/how-tos/reuse-automations/reuse-workflows).
Im folgenden Beispiel wird der Workflow nur ausgeführt, wenn er aus einem anderen Workflow aufgerufen wird:
```yaml
on: workflow_call
```
## `workflow_dispatch`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------- | --------------- | ---------------------------------------------------- | ---------------------------------------------- |
| [workflow\_dispatch](/de/webhooks/webhook-events-and-payloads#workflow_dispatch) | Nicht verfügbar | Letzter Commit für den `GITHUB_REF`-Branch oder -Tag | Branch oder Tag, der den Versand empfangen hat |
> \[!NOTE]
> Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
Damit ein Workflow manuell ausgelöst werden kann, musst du das `workflow_dispatch`-Ereignis konfigurieren. Sie können einen Workflow mit der GitHub API GitHub CLIoder der GitHub Benutzeroberfläche manuell auslösen. Weitere Informationen findest du unter [Manuelles Ausführen eines Workflows](/de/actions/how-tos/manage-workflow-runs/manually-run-a-workflow).
```yaml
on: workflow_dispatch
```
### Bereitstellen von Eingaben
Du kannst benutzerdefinierte Eingabeeigenschaften, Standardeingabewerte und erforderliche Eingaben für das Ereignis direkt im Workflow konfigurieren. Wenn du das Ereignis auslöst, kannst du `ref` und alle `inputs` angeben. Wenn der Workflow ausgeführt wird, kannst du auf die Eingabewerte im `inputs`-Kontext zugreifen. Weitere Informationen findest du unter [Kontextreferenz](/de/actions/reference/workflows-and-actions/contexts).
> \[!NOTE]
>
> * Der Workflow empfängt auch die Eingaben im `github.event.inputs`-Kontext. Die Informationen im Kontext `inputs` und `github.event.inputs` sind identisch, außer dass der Kontext `inputs` boolesche Werte als solche beibehält, anstatt sie in Zeichenfolgen zu konvertieren. Der Typ `choice` wird in eine Zeichenfolge aufgelöst und ist eine einzelne auswählbare Option.
> * Die maximale Anzahl von `inputs` Eigenschaften auf oberster Ebene ist 25 .
> * Die maximale Länge der Nutzdaten für `inputs` beträgt 65.535 Zeichen.
In diesem Beispiel werden Eingaben namens `logLevel`, `tags` und `environment` definiert. Du übergibst Werte für diese Eingaben an den Workflow, wenn du ihn ausführst. Dieser Workflow gibt die Werte dann mit den Kontexteigenschaften `inputs.logLevel`, `inputs.tags` und `inputs.environment` in das Protokoll aus.
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Log level: $LEVEL"
echo "Tags: $TAGS"
echo "Environment: $ENVIRONMENT"
env:
LEVEL: ${{ inputs.logLevel }}
TAGS: ${{ inputs.tags }}
ENVIRONMENT: ${{ inputs.environment }}
```
Wenn du diesen Workflow über einen Browser ausführst, musst du Werte für die erforderlichen Eingaben manuell eingeben, bevor der Workflow ausgeführt wird.
Sie können eingaben auch übergeben, wenn Sie einen Workflow aus einem Skript ausführen oder mithilfe von GitHub CLI. Beispiel:
```shell
gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging
```
Weitere Informationen finden Sie in den GitHub CLI Informationen in [Manuelles Ausführen eines Workflows](/de/actions/how-tos/manage-workflow-runs/manually-run-a-workflow).
## `workflow_run`
| Payload des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------- | -------------- |
| [`workflow_run`](/de/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`
- `requested`
- `in_progress` | Letzter Commit an Default-Branch | Default-Branch |
> \[!NOTE]
> \*
> Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Der `requested` Aktivitätstyp tritt nicht auf, wenn ein Workflow erneut ausgeführt wird. Informationen zu den einzelnen Aktivitätstypen findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#workflow_run). Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort `types` kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn die Workflowdatei im Standardbranch vorhanden ist.
> * Du kannst `workflow_run` nicht verwenden, um mehr als drei Ebenen von Workflows miteinander zu verketten. Wenn du beispielsweise versuchst, fünf Workflows (namens `B` bis `F`) für eine sequenzielle Ausführung auszulösen, nachdem ein erster Workflow `A` ausgeführt wurde (d. h. `A` → `B` → `C` → `D` → `E` → `F`), werden die Workflows `E` und `F` nicht ausgeführt.
Dieses Ereignis tritt auf, wenn eine Workflowausführung angefordert oder abgeschlossen wird. Es ermöglicht dir, einen Workflow basierend auf der Ausführung oder Fertigstellung eines anderen Workflows auszuführen. Der vom Ereignis `workflow_run` gestartete Workflow kann auf Geheimnisse und Schreibtoken zugreifen, auch wenn der vorherige Workflow nicht dazu in der Lage war. Dies ist in Fällen nützlich, in denen der vorherige Workflow absichtlich nicht privilegiert ist, du aber eine privilegierte Aktion in einem späteren Workflow ausführen musst.
> \[!WARNING]
> Das Ausführen nicht vertrauenswürdigen Codes beim Trigger `workflow_run` kann zu Sicherheitsrisiken führen. Zu diesen Sicherheitsrisiken gehören Cachepoisoning und das Gewähren unbeabsichtigten Zugriffs auf Schreibberechtigungen oder Geheimnisse. Weitere Informationen findest du unter [Referenz zur sicheren Verwendung](/de/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) in der GitHub Enterprise Cloud-Dokumentation und [Verhindern von pwn-Anforderungen](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) auf der GitHub Security Lab-Website.
In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate Workflow „Tests ausführen“ abgeschlossen ist.
```yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
```
Wenn du mehrere `workflows` für das `workflow_run`-Ereignis angibst, muss nur einer der Workflows ausgeführt werden. Ein Workflow mit dem folgenden Trigger wird beispielsweise ausgeführt, wenn der Workflow „Staging“ oder der Workflow „Lab“ abgeschlossen ist.
```yaml
on:
workflow_run:
workflows: [Staging, Lab]
types:
- completed
```
### Ausführen eines Workflows basierend auf dem Abschluss eines anderen Workflows
Eine Workflowausführung wird unabhängig vom Abschluss des vorherigen Workflows ausgelöst. Wenn du einen Auftrag oder Schritt basierend auf dem Ergebnis des auslösenden Workflows ausführen möchtest, kannst du eine Bedingung mit der Eigenschaft `github.event.workflow_run.conclusion` verwenden. Dieser Workflow wird beispielsweise ausgeführt, wenn ein Workflow mit dem Namen „Build“ abgeschlossen ist, aber der Auftrag `on-success` wird nur ausgeführt, wenn der Workflow „Build“ erfolgreich war, und der Auftrag `on-failure` wird nur ausgeführt, wenn der Workflow „Build“ fehlgeschlagen ist:
```yaml
on:
workflow_run:
workflows: [Build]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- run: echo 'The triggering workflow passed'
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
- run: echo 'The triggering workflow failed'
```
### Einschränken der Ausführung deines Workflows basierend auf Branches
Mit dem Filter `branches` oder `branches-ignore` kannst du angeben, in welchen Branches der auslösende Workflow ausgeführt werden muss, um deinen Workflow auszulösen. Weitere Informationen findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_runbranchesbranches-ignore). Beispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens `Build` in einem Branch namens `canary` ausgeführt wird.
```yaml
on:
workflow_run:
workflows: [Build]
types: [requested]
branches: [canary]
```
### Verwenden von Daten aus dem auslösenden Workflow
Du kannst auf den [`workflow_run`-Ereignis-Payload](/de/webhooks/webhook-events-and-payloads#workflow_run) zugreifen, der dem Workflow entspricht, der deinen Workflow ausgelöst hat. Wenn dein auslösender Workflow beispielsweise Artefakte generiert, kann ein mit dem Ereignis `workflow_run` ausgelöster Workflow auf diese Artefakte zugreifen.
Der folgende Workflow lädt Daten als Artefakte hoch. (In diesem vereinfachten Beispiel sind die Daten die Pull-Request-Nummer.)
```yaml
name: Upload data
on:
pull_request:
jobs:
upload:
runs-on: ubuntu-latest
steps:
- name: Save PR number
env:
PR_NUMBER: ${{ github.event.number }}
run: |
mkdir -p ./pr
echo $PR_NUMBER > ./pr/pr_number
- uses: actions/upload-artifact@v4
with:
name: pr_number
path: pr/
```
Wenn eine Ausführung des obigen Workflows abgeschlossen ist, löst sie eine Ausführung des folgenden Workflows aus. Der folgende Workflow verwendet den `github.event.workflow_run` Kontext und die actions/download-artifact\@v5 Aktion, um das Artefakt herunterzuladen, das vom obigen Workflow hochgeladen wurde, und kommentiert dann die Pullanforderung, deren Nummer als Artefakt hochgeladen wurde.
```yaml
name: Use the data
on:
workflow_run:
workflows: [Upload data]
types:
- completed
jobs:
download:
runs-on: ubuntu-latest
steps:
- name: 'Download artifact'
uses: actions/download-artifact@v5
with:
name: pr_number
# do not extract in the workspace dir that may contain executable scripts
path: ${{ runner.temp }}/artifacts
run-id: ${{ github.event.workflow_run.id }}
github-token: ${{ secrets.GITHUB_TOKEN }}
- name: 'Comment on PR'
uses: actions/github-script@v8
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const fs = require('fs');
const path = require('path');
const temp = '${{ runner.temp }}/artifacts';
const issue_number_raw = fs.readFileSync(path.join(temp, 'pr_number'), 'utf8').trim();
const issue_number = Number(issue_number_raw);
if (!Number.isInteger(issue_number)) {
throw new Error(`Invalid PR number in pr_number artifact: "${issue_number_raw}"`);
}
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: 'Thank you for the PR!'
});
```