Ereignisse, die Workflows auslösen

Configuring workflow events

You can configure workflows to run for one or more events using the on workflow syntax. Weitere Informationen finden Sie unter „Workflow-Syntax für GitHub Actions“.

Example: Using a single event

# Triggered when code is pushed to any branch in a repository
on: push

Example: Using a list of events

# Triggers the workflow on push or pull request events
on: [push, pull_request]

Example: Using multiple events with activity types or configuration

Wenn Du Aktivitätstypen oder Konfigurationen für ein Ereignis angeben musst, musst Du jedes Ereignis separat konfigurieren. Du musst einen Doppelpunkt (:) an alle Ereignisse anhängen, einschließlich Ereignisse ohne Konfiguration.

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:

1. An event occurs on your repository, and the resulting event has an associated commit SHA and Git ref.

2. Das Verzeichnis .github/workflows in Deinem Repository wird nach Workflow-Dateien des zugehörigen Commit-SHA oder der zugehörigen Git Ref durchsucht. Die Workflow-Dateien müssen in diesem Commit-SHA oder dieser Git Ref vorhanden sein, um berücksichtigt zu werden.

   Wenn zum Beispiel das Ereignis in einem bestimmten Repository-Zweig aufgetreten ist, müssen die Workflow-Dateien im Repository dieses Zweiges vorhanden sein.

3. Die Workflow-Dateien für diesen Commit-SHA und diese Git Ref werden überprüft und für alle Workflows, deren on:-Werte zu dem auslösenden Ereignis passen, wird ein neuer Workflow-Lauf angestoßen.

   Der Workflow läuft auf dem Code Deines Repositorys mit dem selben Commit-SHA und derselben Git Ref wie das auslösende Ereignis. Wenn ein Workflow läuft, setzt GitHub Enterprise Server die Umgebungsvariablen GITHUB_SHA (Commit-SHA) und GITHUB_REF (Git Ref) in der Umgebung auf dem Runner. Weitere Informationen findest Du unter „Umgebungsvariablen verwenden“.

Geplante Ereignisse

The schedule event allows you to trigger a workflow at a scheduled time.

Zeitplan

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
–	–	Letzter Commit im Standard-Branch	Standardbranch

Du kannst einen Workflow mit Hilfe von POSIX cron syntax so planen, dass er zu bestimmten UTC-Zeiten ausgeführt wird. Geplante Workflows laufen auf dem jüngsten Commit auf dem Standard- oder Basisbranch. Das kürzeste Intervall, in dem Sie geplante Workflows ausführen können, ist einmal alle 5 Minuten.

This example triggers the workflow every day at 5:30 and 17:30 UTC:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

Die Cron-Syntax umfasst fünf durch Leerzeichen getrennte Felder, die jeweils eine Zeiteinheit darstellen.

┌───────────── Minute (0–59)
│ ┌───────────── Stunde (0–23)
│ │ ┌───────────── Tag (1–31)
│ │ │ ┌───────────── Monat (1–12 oder JAN–DEZ)
│ │ │ │ ┌───────────── Wochentag (0–6 oder SON–SAM)
│ │ │ │ │                                   
│ │ │ │ │
│ │ │ │ │
* * * * *

In den fünf Feldern stehen die folgenden Operatoren zur Auswahl:

Operator	Beschreibung	Beispiel
*	Beliebiger Wert	* * * * * wird jeden Tag jede Minute ausgeführt.
,	Trennzeichen in Werteliste	2,10 4,5 * * * wird jeden Tag bei Minute 2 und 10 der 4. und 5. Stunde ausgeführt.
-	Wertebereich	0 4-6 * * * wird bei Minute 0 der 4., 5. und 6. Stunde ausgeführt.
/	Schrittwerte	20/15 * * * * wird alle 15 Minuten ausgeführt, von Minute 20 bis Minute 59 (also bei Minute 20, 35 und 50).

Mit crontab guru können Sie die Cron-Syntax erzeugen und den Ausführungszeitpunkt bestätigen. Als Einstiegshilfe steht eine Liste mit crontab-guru-Beispielen bereit.

Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, please see "Notifications for workflow runs."

Manual events

You can manually trigger workflow runs. To trigger specific workflows in a repository, use the workflow_dispatch event. To trigger more than one workflow in a repository and create custom events and event types, use the repository_dispatch event.

workflow_dispatch

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
workflow_dispatch	–	Letzter Commit im Branch GITHUB_REF	Branch, der den Dispatch empfangen hat

You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. Wenn der Workflow ausgeführt wird, können Sie auf die Eingabewerte im github.event.inputs Kontextzugreifen. Weitere Informationen finden Sie unter „Kontexte“.

You can manually trigger a workflow run using the GitHub API and from GitHub. For more information, see "Manually running a workflow."

When you trigger the event on GitHub, you can provide the ref and any inputs directly on GitHub. For more information, see "Using inputs and outputs with an action."

To trigger the custom workflow_dispatch webhook event using the REST API, you must send a POST request to a GitHub API endpoint and provide the ref and any required inputs. For more information, see the "Create a workflow dispatch event" REST API endpoint.

Beispiel

To use the workflow_dispatch event, you need to include it as a trigger in your GitHub Actions workflow file. The example below only runs the workflow when it's manually triggered:

on: workflow_dispatch

Example workflow configuration

In diesem Beispiel wird der Name definiert und ein- und zu Hause verwendet, und sie werden mit den Kontexten <code>github.event.inputs.name und github.event.inputs.home gedruckt. If a home isn't provided, the default value 'The Octoverse' is printed.

name: Manually triggered workflow
on:
  workflow_dispatch:
    inputs:
      name:
        description: 'Person to greet'
        required: true
        default: 'Mona the Octocat'
      home:
        description: 'location'
        required: false
        default: 'The Octoverse'

jobs:
  say_hello:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Hello ${{ github.event.inputs.name }}!"
          echo "- in{{ github.event.inputs.home }}!"

repository_dispatch

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
repository_dispatch	–	Letzter Commit im Standard-Branch	Standard-Branch

Mit der GitHub Enterprise Server-API können Sie das Webhook-Ereignis repository_dispatch auslösen, wenn ein Workflow für eine Aktivität ausgelöst werden soll, die außerhalb von GitHub abläuft. For more information, see "Create a repository dispatch event."

Soll das benutzerdefinierte Webhook-Ereignis repository_dispatch ausgelöst werden, senden Sie eine POST-Anfrage an einen GitHub Enterprise Server-API-Endpunkt, und geben Sie den Namen für einen event_type als Beschreibung für den Aktivitätstyp an. Soll ein Workflow-Lauf ausgelöst werden, konfigurieren Sie außerdem den Workflow für die Verwendung des Ereignisses repository_dispatch.

Beispiel

Standardmäßig lösen alle event_types einen Workflow aus. Du kannst Deinen Workflow darauf beschränken, zu laufen, wenn ein bestimmter Wert als event_type in der Webhoo-Nutzlast des repository_dispatch gesendet wird. Du definierst die Ereignistypen, die in der Nutzlast des repository_dispatch gesendet werden, wenn Du das Repositorydispatch-Ereignis erstellst.

on:
  repository_dispatch:
    types: [opened, deleted]

Webhook-Ereignisse

You can configure your workflow to run when webhook events are generated on GitHub Enterprise Server. Einige Ereignisse werden von mehreren Aktivitätstypen ausgelöst. Wird ein Ereignis von mehreren Aktivitätstypen ausgelöst, können Sie die Aktivitätstypen angeben, die die Ausführung des Workflows auslösen sollen. For more information, see "Webhooks."

Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "Webhook events and payloads."

check_run

Führt den Workflow aus, wenn das Ereignis check_run eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Check runs."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
check_run	- created - rerequested - completed	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

For example, you can run a workflow when a check run has been rerequested or completed.

on:
  check_run:
    types: [rerequested, completed]

check_suite

Führt den Workflow aus, wenn das Ereignis check_suite eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Check suites."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
check_suite	- completed - requested - rerequested	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Sie können einen Workflow beispielsweise ausführen, wenn eine Prüfsuite erneut angefordert (rerequested) oder abgeschlossen (completed) wurde.

on:
  check_suite:
    types: [rerequested, completed]

create

Führt den Workflow aus, wenn ein Benutzer einen Branch oder ein Tag erstellt, wodurch das Ereignis create ausgelöst wird. For information about the REST API, see "Create a reference."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
create	–	Letzter Commit im erstellten Branch oder Tag	Erstellter Branch oder Tag

Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis create eintritt.

on:
  create

delete

Führt den Workflow aus, wenn ein Benutzer einen Branch oder ein Tag löscht, wodurch das Ereignis delete ausgelöst wird. For information about the REST API, see "Delete a reference."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
delete	–	Letzter Commit im Standard-Branch	Standard-Branch

Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis delete eintritt.

on:
  delete

deployment

Führt den Workflow aus, wenn ein Benutzer eine Bereitstellung erstellt, wodurch das Ereignis deployment ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "Deployments."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
deployment	–	Bereitzustellender Commit	Bereitzustellender Branch oder Tag (leer bei Commit)

Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis deployment eintritt.

on:
  deployment

deployment_status

Führt den Workflow aus, wenn ein Dritter einen Bereitstellungsstatus angibt, wodurch das Ereignis deployment_status ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "Create a deployment status."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
deployment_status	–	Bereitzustellender Commit	Bereitzustellender Branch oder Tag (leer bei Commit)

Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis deployment_status eintritt.

on:
  deployment_status

Fork

Führt den Workflow aus, wenn ein Benutzer per „Fork“ (Gabel-Kopie) ein Repository kopiert, wodurch das Ereignis fork ausgelöst wird. For information about the REST API, see "Create a fork."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Fork	–	Letzter Commit im Standard-Branch	Standard-Branch

Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis fork eintritt.

on:
  fork

gollum

Führt den Workflow aus, wenn ein Benutzer eine Wiki-Seite erstellt oder aktualisiert, wodurch das Ereignis gollum ausgelöst wird.

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
gollum	–	Letzter Commit im Standard-Branch	Standard-Branch

Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis gollum eintritt.

on:
  gollum

issue_comment

Führt Deinen Workflow jedes Mal aus, wenn das Ereignis issue_comment eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Issue comments."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
issue_comment	- created - edited - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Problemkommentar erstellt (created) oder gelöscht (deleted) wurde.

on:
  issue_comment:
    types: [created, deleted]

The issue_comment event occurs for comments on both issues and pull requests. To determine whether the issue_comment event was triggered from an issue or pull request, you can check the event payload for the issue.pull_request property and use it as a condition to skip a job.

For example, you can choose to run the pr_commented job when comment events occur in a pull request, and the issue_commented job when comment events occur in an issue.

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Comment on PR #${{ github.event.issue.number }}"

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Comment on issue #${{ github.event.issue.number }}"

Issues (Lieferungen)

Führt den Workflow aus, wenn das Ereignis issues eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Issues."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Issues (Lieferungen)	- opened - edited - deleted - transferred - pinned - unpinned - closed - reopened - assigned - unassigned - labeled - unlabeled - locked - unlocked - milestoned - demilestoned	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Problem geöffnet (opened) oder bearbeitet (edited) wurde oder wenn dafür ein Meilenstein gesetzt wurde (milestoned).

on:
  issues:
    types: [opened, edited, milestoned]

Kennzeichnung

Führt den Workflow aus, wenn das Ereignis label eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Labels."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Kennzeichnung	- created - edited - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Sie können einen Workflow beispielsweise ausführen, wenn eine Kennzeichnung erstellt (created) oder gelöscht (deleted) wurde.

on:
  label:
    types: [created, deleted]

Meilensteine

Führt Deinen Workflow aus, wenn das Ereignis milestone eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Milestones."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Meilensteine	- created - closed - opened - edited - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn eine Meilenstein geöffnet (opened) oder gelöscht (deleted) wurde.

on:
  milestone:
    types: [opened, deleted]

page_build

Führt den Workflow aus, wenn ein Benutzer einen Push an einen GitHub Enterprise Server-Pages-fähigen Branch vornimmt, wodurch das Ereignis page_build ausgelöst wird. For information about the REST API, see "Pages."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
page_build	–	Letzter Commit im Standard-Branch	–

Sie können einen Workflow beispielsweise ausführen, wenn das Ereignis page_build eintritt.

on:
  page_build

project (Projekt)

Führt den Workflow aus, wenn das Ereignis project eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Projects."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
project (Projekt)	- created - updated - closed - reopened - edited - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Sie können einen Workflow beispielsweise ausführen, wenn ein Projekt erstellt (created) oder gelöscht (deleted) wurde.

on:
  project:
    types: [created, deleted]

project_card

Führt den Workflow aus, wenn das Ereignis project_card eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Project cards."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
project_card	- created - moved - converted to an issue - edited - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Sie können einen Workflow beispielsweise ausführen, wenn ein Projektticket geöffnet (opened) oder gelöscht (deleted) wurde.

on:
  project_card:
    types: [created, deleted]

project_column

Führt Deinen Workflow aus, wenn das Ereignis project_column eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Project columns."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
project_column	- created - updated - moved - deleted	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn eine Projektspalte erstellt (created) oder gelöscht (deleted) wurde.

on:
  project_column:
    types: [created, deleted]

public

Führt Deinen Workflow aus, wenn ein Benutzer ein privates Repository öffentlich macht, wodurch das Ereignis public ausgelöst wird. For information about the REST API, see "Edit repositories."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
public	–	Letzter Commit im Standard-Branch	Standard-Branch

Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis public eintritt.

on:
  public

pull_request

Führt Deinen Workflow aus, wenn das Ereignis pull_request eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Pull requests."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
pull_request	- assigned - unassigned - labeled - unlabeled - opened - edited - closed - reopened - synchronize - converted_to_draft - ready_for_review - locked - unlocked - review_requested - review_request_removed	Letzter Merge-Commit im Branch GITHUB_REF	PR-Merge-Branch refs/pull/:prNumber/merge

Mit dem Stichwort types erweitern oder begrenzen Sie die Standard-Aktivitätstypen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise dann ausführen, wenn ein Pull Request zugewiesen (assigned), geöffnet (opened), synchronisiert (synchronize) oder erneut geöffnet (reopened) wurde.

on:
  pull_request:
    types: [assigned, opened, synchronize, reopened]

Pull-Request-Ereignisse für geforkte Repositorys

Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.

Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.

Mit Ausnahme von GITHUB_TOKEN werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."

pull_request_review

Führt Deinen Workflow aus, wenn das Ereignis pull_request_review eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Pull request reviews."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
pull_request_review	- submitted - edited - dismissed	Letzter Merge-Commit im Branch GITHUB_REF	PR-Merge-Branch refs/pull/:prNumber/merge

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Pull-Request-Review bearbeitet (edited) oder verworfen (dismissed) wurde.

on:
  pull_request_review:
    types: [edited, dismissed]

Pull-Request-Ereignisse für geforkte Repositorys

Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.

Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.

Mit Ausnahme von GITHUB_TOKEN werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."

pull_request_review_comment

Führt den Workflow aus, wenn ein Kommentar zum vereinheitlichten Diff für einen Pull Request geändert wird, wodurch das Ereignis pull_request_review_comment ausgelöst wird. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see Review comments.

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
pull_request_review_comment	- created - edited - deleted	Letzter Merge-Commit im Branch GITHUB_REF	PR-Merge-Branch refs/pull/:prNumber/merge

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Pull-Request-Review-Kommentar erstellt (created) oder gelöscht (deleted) wurde.

on:
  pull_request_review_comment:
    types: [created, deleted]

Pull-Request-Ereignisse für geforkte Repositorys

Wenn Sie einen Pull Request an das Basis-Repository aus einem geforkten Repository heraus erstellen, sendet GitHub das Ereignis pull_request an das Basis-Repository, und im geforkten Repository treten keine Pull-Request-Ereignisse ein.

Workflows werden standardmäßig nicht für geforkte Repositorys ausgeführt. Du musst GitHub Actions auf der Registerkarte Actions (Aktionen) im geforkten Repository aktivieren.

Mit Ausnahme von GITHUB_TOKEN werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird. The permissions for the GITHUB_TOKEN in forked repositories is read-only. Weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN."

Push

Führt den Workflow aus, wenn ein Benutzer einen Push an einen Repository-Branch durchführt, wodurch das Ereignis push ausgelöst wird.

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Push	–	Gepushter Commit, außer beim Löschen eines Branches (nur beim Standard-Branch)	Aktualisierter Ref

Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis push eintritt.

on:
  push

registry_package

Führt Deinen Workflow aus, wenn ein Paket veröffentlicht oder aktualisiert wird. Weitere Informationen findest Du unter „Pakete mit GitHub Packages verwalten".

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
registry_package	- published - updated	Commit des veröffentlichten Pakets	Branch oder Tag des veröffentlichten Pakets

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Paket veröffentlicht (published) wurde.

on:
  registry_package:
    types: [published]

Release

Führt Deinen Workflow aus, wenn das Ereignis release eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Releases."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Release	- published - unpublished - created - edited - deleted - prereleased - released	Letzter Commit in dem bezeichneten Release	Bezeichnung des Releases

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Führe einen Workflow beispielsweise aus, wenn ein Release veröffentlicht (published) wurde.

on:
  release:
    types: [published]

Status

Führt Deinen Workflow aus, wenn sich der Status eines Git-Commit ändert, wodurch das Ereignis status ausgelöst wird. For information about the REST API, see Statuses.

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
Status	–	Letzter Commit im Standard-Branch	–

Du kannst einen Workflow beispielsweise ausführen, wenn das Ereignis status eintritt.

on:
  status

beobachten

Führt Deinen Workflow aus, wenn das Ereignis watch eintritt. Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. For information about the REST API, see "Starring."

Nutzlast des Webhook-Ereignisses	Aktivitätstypen	GITHUB_SHA	GITHUB_REF
beobachten	- started	Letzter Commit im Standard-Branch	Standard-Branch

Standardmäßig lösen alle Aktivitätstypen die Ausführung eines Workflows aus. Mit dem Stichwort types kannst Du die Workflow-Ausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Du kannst einen Workflow beispielsweise ausführen, wenn ein Benutzer ein Repository mit Sternen bewertet, also wenn das Beobachtungsereignis mit dem Aktivitätstyp started ausgelöst wird.

on:
  watch:
    types: [started]

To run a workflow job conditionally based on the result of the previous workflow run, you can use the jobs.<job_id>.if or jobs.<job_id>.steps[*].if conditional combined with the conclusion of the previous run. Ein Beispiel:

on:
  workflow_run:
    workflows: ["Build"]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      ...
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      ...

Neue Workflows mit einem persönlichen Zugangs-Token auslösen

Wenn Du den GITHUB_TOKEN des Repository verwendest, um Aufgaben im Auftrag der GitHub Actions App auszuführen, werden die vom GITHUB_TOKEN ausgelösten Ereignisse keine neue Workflow-Ausführung bereitstellen. Dadurch wird verhindert, dass Du versehentlich rekursive Workflow-Ausführung erstellst. Wenn z. B. eine Workflow-Ausführung Code mit dem GITHUB_TOKEN des Repository pusht, wird kein neuer Workflow ausgeführt, auch wenn das Repository einen Workflow enthält, welcher konfiguriert ist zur Ausführung wenn push Ereignisse auftreten. weitere Informationen findest Du unter „Authentifizierung mit dem GITHUB_TOKEN“.

Wenn Du einen Workflow aus einem Workflow-Lauf auslösen möchtest, kannst Du das Ereignis mithilfe eines persönlichen Zugangs-Tokens auslösen. Du musst einen persönlichen Zugangs-Token erstellen und ihn als Geheimnis speichern. Um Dein Nutzungskosten für GitHub Actions zu minimieren, pass auf, dass Du keine rekursiven oder unbeabsichtigten Workflow-Läufe erzeugst. For more information on storing a personal access token as a secret, see "Creating and storing encrypted secrets."