Ereignisse, die Workflows auslösen

Sie können konfigurieren, dass Ihre Workflows zu einem geplanten Zeitpunkt ausgeführt werden oder dann, wenn eine bestimmte Aktivität auf GitHub Enterprise Server stattfindet oder ein Ereignis außerhalb von GitHub Enterprise Server auftritt.

Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.

Configuring workflow events

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

Example: Using a single event

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

Example: Using a list of events

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

Example: Using multiple events with activity types or configuration

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

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

Hinweis: Du kannst einen neuen Workflow-Lauf nicht mithilfe des GITHUB_TOKEN anstoßen. Weitere Informationen findest Du unter „Neue Workflows mit einem persönlichen Zugriffstoken anstoßen“.

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

  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.

Note: The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.

Zeitplan

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Letzter Commit im Standard-BranchStandardbranch

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:

OperatorBeschreibungBeispiel
*Beliebiger Wert* * * * * wird jeden Tag jede Minute ausgeführt.
,Trennzeichen in Werteliste2,10 4,5 * * * wird jeden Tag bei Minute 2 und 10 der 4. und 5. Stunde ausgeführt.
-Wertebereich0 4-6 * * * wird bei Minute 0 der 4., 5. und 6. Stunde ausgeführt.
/Schrittwerte20/15 * * * * wird alle 15 Minuten ausgeführt, von Minute 20 bis Minute 59 (also bei Minute 20, 35 und 50).

Hinweis: GitHub Actions bietet keine Unterstützung für die nicht standardmäßige Syntax @yearly, @monthly, @weekly, @daily, @hourly und @reboot.

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

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

Manual events

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

workflow_dispatch

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
workflow_dispatchLetzter Commit im Branch GITHUB_REFBranch, 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-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
repository_dispatchLetzter Commit im Standard-BranchStandard-Branch

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

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

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

Beispiel

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

on:
  repository_dispatch:
    types: [opened, deleted]

Webhook-Ereignisse

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

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

check_run

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
check_run- created
- rerequested
- completed
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Hinweis: Um rekursive Workflows zu verhindern, löst dieses Ereignis keine Workflows aus, wenn die Prüfsuite von GitHub Actions erstellt wurde.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
check_suite- completed
- requested
- rerequested
Letzter Commit im Standard-BranchStandard-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-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
createLetzter Commit im erstellten Branch oder TagErstellter Branch oder Tag

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

on:
  create

delete

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deleteLetzter Commit im Standard-BranchStandard-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-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deploymentBereitzustellender CommitBereitzustellender 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-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deployment_statusBereitzustellender CommitBereitzustellender Branch oder Tag (leer bei Commit)

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

on:
  deployment_status

Note: When a deployment status's state is set to inactive, a webhook event will not be created.

Fork

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
ForkLetzter Commit im Standard-BranchStandard-Branch

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

on:
  fork

gollum

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
gollumLetzter Commit im Standard-BranchStandard-Branch

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

on:
  gollum

issue_comment

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
issue_comment- created
- edited
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  issue_comment:
    types: [created, deleted]

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

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

on: issue_comment

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

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

Issues (Lieferungen)

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Issues (Lieferungen)- opened
- edited
- deleted
- transferred
- pinned
- unpinned
- closed
- reopened
- assigned
- unassigned
- labeled
- unlabeled
- locked
- unlocked
- milestoned
- demilestoned
Letzter Commit im Standard-BranchStandard-Branch

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

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

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

Kennzeichnung

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Kennzeichnung- created
- edited
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  label:
    types: [created, deleted]

Meilensteine

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Meilensteine- created
- closed
- opened
- edited
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  milestone:
    types: [opened, deleted]

page_build

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
page_buildLetzter Commit im Standard-Branch

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

on:
  page_build

project (Projekt)

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
project (Projekt)- created
- updated
- closed
- reopened
- edited
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  project:
    types: [created, deleted]

project_card

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
project_card- created
- moved
- converted to an issue
- edited
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  project_card:
    types: [created, deleted]

project_column

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
project_column- created
- updated
- moved
- deleted
Letzter Commit im Standard-BranchStandard-Branch

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

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

on:
  project_column:
    types: [created, deleted]

public

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
publicLetzter Commit im Standard-BranchStandard-Branch

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

on:
  public

pull_request

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

Hinweise:

  • By default, a workflow only runs when a pull_request's activity type is opened, synchronize, or reopened. Sollen Workflows für weitere Aktivitätstypen ausgelöst werden, verwende das Schlüsselwort types.
  • Workflows will not run on pull_request activity if the pull request has a merge conflict. The merge conflict must be resolved first.
Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_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
- auto_merge_enabled
- auto_merge_disabled
Letzter Merge-Commit im Branch GITHUB_REFPR-Merge-Branch refs/pull/:prNumber/merge

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

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

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

Pull-Request-Ereignisse für geforkte Repositorys

Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.

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

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

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

Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.

pull_request_review

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
pull_request_review- submitted
- edited
- dismissed
Letzter Merge-Commit im Branch GITHUB_REFPR-Merge-Branch refs/pull/:prNumber/merge

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

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

on:
  pull_request_review:
    types: [edited, dismissed]

Pull-Request-Ereignisse für geforkte Repositorys

Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.

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

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

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

Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.

pull_request_review_comment

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
pull_request_review_comment- created
- edited
- deleted
Letzter Merge-Commit im Branch GITHUB_REFPR-Merge-Branch refs/pull/:prNumber/merge

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

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

on:
  pull_request_review_comment:
    types: [created, deleted]

Pull-Request-Ereignisse für geforkte Repositorys

Hinweis: Workflows werden nicht für private Basis-Repositorys ausgeführt, wenn Du einen Pull Request aus einem geforkten Repository heraus öffnest.

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

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

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

Note: Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.

pull_request_target

This event runs in the context of the base of the pull request, rather than in the merge commit as the pull_request event does. This prevents executing unsafe workflow code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows you to do things like create workflows that label and comment on pull requests based on the contents of the event payload.

Warning: The pull_request_target event is granted a read/write repository token and can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch, and to help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab website.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
pull_request_target- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- converted_to_draft
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
Last commit on the PR base branchPR base branch

By default, a workflow only runs when a pull_request_target's activity type is opened, synchronize, or reopened. Sollen Workflows für weitere Aktivitätstypen ausgelöst werden, verwende das Schlüsselwort types. 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_target:
    types: [assigned, opened, synchronize, reopened]

Push

Hinweis: Die Webhook-Nutzlast, die Für GitHub-Aktionen verfügbar ist, enthält im Objekt commit nicht die Attribute added, removed und modified. Du kannst das vollständige Commit-Objekt mit der REST-API abrufen. For more information, see "Get a commit".

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
PushGepushter 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-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
registry_package- published
- updated
Commit des veröffentlichten PaketsBranch oder Tag des veröffentlichten Pakets

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

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

on:
  registry_package:
    types: [published]

Release

Hinweis: Das Ereignis release wird für Entwurfsversionen nicht ausgelöst.

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Release- published
- unpublished
- created
- edited
- deleted
- prereleased
- released
Letzter Commit in dem bezeichneten ReleaseBezeichnung des Releases

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

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

on:
  release:
    types: [published]

Note: The prereleased type will not trigger for pre-releases published from draft releases, but the published type will trigger. If you want a workflow to run when stable and pre-releases publish, subscribe to published instead of released and prereleased.

Status

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
StatusLetzter Commit im Standard-Branch

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

on:
  status

beobachten

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

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
beobachten- startedLetzter Commit im Standard-BranchStandard-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]

workflow_run

This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. A workflow run is triggered regardless of the result of the previous workflow.

For example, if your pull_request workflow generates build artifacts, you can create a new workflow that uses workflow_run to analyze the results and add a comment to the original pull request.

The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
workflow_run- completed
- requested
Letzter Commit im Standard-BranchStandard-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“.

If you need to filter branches from this event, you can use branches or branches-ignore.

In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.

on:
  workflow_run:
    workflows: ["Run Tests"]
    branches: [main]
    types: 
      - completed
      - requested

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."

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Oder, learn how to contribute.