Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Ereignisse zum Auslösen von Workflows

Du kannst deine Workflows so konfigurieren, dass sie ausgeführt werden, wenn eine bestimmte Aktivität auf GitHub Enterprise Server stattfindet oder ein Ereignis außerhalb von GitHub Enterprise Server eintritt.

Informationen zu Ereignissen, die Workflows auslösen

Workflowtrigger sind Ereignisse, die dazu führen, dass ein Workflow ausgeführt wird. Weitere Informationen zur Verwendung von Workflowtriggern findest du unter Auslösen eines Workflows.

Verfügbare Ereignisse

Einige Ereignisse weisen mehrere Aktivitätstypen auf. Für diese Ereignisse kannst du angeben, welche Aktivitätstypen eine Workflowausführung auslösen. Weitere Informationen dazu, was jeder Aktivitätstyp bedeutet, findest du unter Webhook-Ereignisse und Nutzlasten. Beachte, dass nicht alle Webhook-Ereignisse Workflows auslösen.

branch_protection_rule

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
branch_protection_rule- created
- edited
- deleted
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn Regeln für den Schutz von Branches im Workflow-Repository geändert werden. Weitere Informationen zu Regeln für den Schutz von Branches findest du unter Informationen zu geschützten Branches. Informationen zu den APIs für Regeln für den Schutz von Branches findest du unter BranchProtectionRule in der GraphQL-API-Dokumentation oder Branches in der REST-API-Dokumentation.

Du kannst beispielsweise einen Workflow ausführen, wenn eine Regel für den Schutz von Branches erstellt (created) oder gelöscht (deleted) wurde:

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

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. Weitere Informationen findest du unterErste Schritte mit der Überprüfungs-API. Informationen zu den APIs für die Ausführung von Überprüfungen findest du unter CheckRun in der GraphQL-API-Dokumentation oder Überprüfungen in der REST-API-Dokumentation.

Du kannst z. B. einen Workflow ausführen, wenn eine Überprüfung erneut angefordert (rerequested) oder abgeschlossen (completed) wurde.

on:
  check_run:
    types: [rerequested, completed]

check_suite

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
check_suite- completedLetzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. Obwohl nur der Aktivitätstyp started 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Damit rekursive Workflows verhindert werden, löst dieses Ereignis keine Workflows aus, wenn die Überprüfungssammlung von GitHub Actions erstellt wurde.

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. Weitere Informationen findest du unterErste Schritte mit der Überprüfungs-API. Informationen zu den APIs für Überprüfungssammlungen findest du unter CheckSuite in der GraphQL-API-Dokumentation oder Überprüfungen in der REST-API-Dokumentation.

Du kannst z. B. einen Workflow ausführen, wenn eine Überprüfung abgeschlossen (completed) wurde.

on:
  check_suite:
    types: [completed]

create

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
createNicht zutreffendLetzter Commit im erstellten Branch oder TagErstellter Branch oder Tag

Hinweis: Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags gleichzeitig erstellst.

Führt deinen Workflow aus, wenn ein Git-Verweis (Git-Verzweigung oder -Tag) im Repository des Workflows erstellt wird. Informationen zu den APIs zum Erstellen eines Git-Verweises findest du unter createRef in der GraphQL-API-Dokumentation oder Erstellen eines Verweises in der REST-API-Dokumentation.

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

on:
  create

delete

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deleteLetzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags gleichzeitig löschst.

Führt deinen Workflow aus, wenn ein Git-Verweis (Git-Verzweigung oder -Tag) im Repository des Workflows gelöscht wird. Informationen zu den APIs zum Löschen eines Git-Verweises findest du unter deleteRef in der GraphQL-API-Dokumentation oder Löschen eines Verweises in der REST-API-Dokumentation.

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

on:
  delete

deployment

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deploymentBereitzustellender CommitBereitzustellender 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 einen Git-Verweis. Informationen zu den APIs zum Erstellen einer Bereitstellung findest du unter createDeployment in der GraphQL-API-Dokumentation oder Bereitstellungen in der REST-API-Dokumentation.

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

on:
  deployment

deployment_status

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deployment_statusBereitzustellender CommitBereitzustellender Branch oder Tag (leer bei Commit)

Hinweis: Wenn der Zustand eines Bereitstellungsstatus auf inactive festgelegt ist, wird keine Workflowausführung ausgelöst.

Führt deinen Workflow aus, wenn ein Drittanbieter einen Bereitstellungsstatus bereitstellt. Bereitstellungen, die mit einem Commit-SHA erstellt wurden, verfügen möglicherweise nicht über einen Git-Verweis. Informationen zu den APIs zum Erstellen eines Bereitstellungsstatus findest du unter createDeploymentStatus in der GraphQL-API-Dokumentation oder Erstellen eines Bereitstellungsstatus in der REST-API-Dokumentation.

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

on:
  deployment_status

fork

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
forkLetzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn jemand ein Repository forkt. Informationen zur REST-API findest du unter Erstellen eines Forks.

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

on:
  fork

gollum

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

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn jemand eine Wiki-Seite erstellt oder aktualisiert. Weitere Informationen findest du unter Informationen zu Wikis.

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

on:
  gollum

issue_comment

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn ein Issue oder ein Pull-Request-Kommentar erstellt, bearbeitet oder gelöscht wird. Informationen zu den Issue-Kommentar-APIs findest du unter IssueComment in der GraphQL-API-Dokumentation oder Issue-Kommentare 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.

on:
  issue_comment:
    types: [created, deleted]

issue_comment nur bei Issues oder nur bei 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.

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

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn ein Issue im Repository des Workflows erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Issues in einem Problem das Ereignis issue_comment. Weitere Informationen zu Issues findest du unter Informationen zu Issues. Informationen zu den Issue-APIs findest du unter Issue in der GraphQL-API-Dokumentation oder Issues in der REST-API-Dokumentation.

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

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

label

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
label- created
- edited
- deleted
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn eine Bezeichnung im Repository des Workflows erstellt oder geändert wird. Weitere Informationen zu Bezeichnungen findest du unter Verwalten von Bezeichnungen. Informationen zu den Bezeichnungs-APIs findest du unter Label in der GraphQL-API-Dokumentation oder Bezeichnungen in der REST-API-Dokumentation.

Wenn du deinen Workflow ausführen möchtest, wenn eine Bezeichnung zu einem Issue, einem Pull Request oder einer Diskussion hinzugefügt oder davon entfernt wird, verwende stattdessen den Aktivitätstyp labeled oder unlabeled für die Ereignisse issues, pull_request, pull_request_target oder discussion.

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

on:
  label:
    types: [created, deleted]

milestone

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

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. Informationen zu den Meilenstein-APIs findest du unter Milestone in der GraphQL-API-Dokumentation oder Meilensteine in der REST-API-Dokumentation.

Wenn du deinen Workflow ausführen möchtest, wenn ein Issue einem Meilenstein hinzugefügt oder von ihm entfernt wird, verwende stattdessen den Aktivitätstyp milestoned oder demilestoned für das Ereignis issues.

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

on:
  milestone:
    types: [opened, deleted]

page_build

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

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn eine Person an einen Branch pusht, der die Veröffentlichungsquelle für GitHub Pages ist, wenn GitHub Pages für das Repository aktiviert sind. Weitere Informationen zu GitHub Pages-Veröffentlichungsquellen findest du unter Konfigurieren einer Veröffentlichungsquelle für deine GitHub Pages-Website. Informationen zur REST-API findest du unter Seiten.

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

on:
  page_build

project

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
project- created
- closed
- reopened
- edited
- deleted
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Der Aktivitätstyp edited bezieht sich auf den Zeitpunkt, an dem ein Projektboard, nicht eine Spalte oder Karte im Projektboard, bearbeitet wird. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Dieses Ereignis tritt nur für Projekte auf, die im Besitz des Repositorys des Workflows sind, nicht für organisationseigene oder benutzereigene Projekte oder für Projekte im Besitz eines anderen Repositorys.

Führt den Workflow aus, wenn ein Projektboard erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Karten oder Spalten in einem Projektboard stattdessen die Ereignisse project_card oder project_column. Weitere Informationen zu Projektboards findest du unter Informationen zu Projektboards. Informationen zu den Projektboard-APIs findest du unter Project in der GraphQL-API-Dokumentation oder Projekte in der REST-API-Dokumentation.

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

on:
  project:
    types: [created, deleted]

project_card

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
project_card- created
- moved
- converted in ein Issue
- edited
- deleted
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Dieses Ereignis tritt nur für Projekte auf, die im Besitz des Repositorys des Workflows sind, nicht für organisationseigene oder benutzereigene Projekte oder für Projekte im Besitz eines anderen Repositorys.

Führt deinen Workflow aus, wenn eine Karte auf einem Projektboard erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Projektboards oder Spalten in einem Projektboard stattdessen das Ereignis project oder project_column. Weitere Informationen zu Projektboards findest du unter Informationen zu Projektboards. Informationen zu den Projektkarten-APIs findest du unter ProjectCard in der GraphQL-API-Dokumentation oder Projektkarten in der REST-API-Dokumentation.

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

on:
  project_card:
    types: [created, deleted]

project_column

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Dieses Ereignis tritt nur für Projekte auf, die im Besitz des Repositorys des Workflows sind, nicht für organisationseigene oder benutzereigene Projekte oder für Projekte im Besitz eines anderen Repositorys.

Führt deinen Workflow aus, wenn eine Spalte auf einem Projektboard erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Projektboards oder Karten in einem Projektboard stattdessen das Ereignis project oder project_card. Weitere Informationen zu Projektboards findest du unter Informationen zu Projektboards. Informationen zu den Projektspalten-APIs findest du unter ProjectColumn in der GraphQL-API-Dokumentation oder Projektspalten in der REST-API-Dokumentation.

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

on:
  project_column:
    types: [created, deleted]

public

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

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn sich das Repository deines Workflows von privat in öffentlich ändert. Informationen zur REST-API findest du unter Bearbeiten von Repositorys.

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

on:
  public

pull_request

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-Mergebranch refs/pull/:prNumber/merge

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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.

Hinweis: 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.

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. Verwende für Aktivitäten im Zusammenhang mit Pull-Request-Überprüfungen, Pull-Request-Überprüfungskommentaren oder Pull-Request-Kommentaren stattdessen die Ereignisse pull_request_review, pull_request_review_comment oder issue_comment. Informationen zu den Pull-Request-APIs findest du unter PullRequest in der GraphQL-API-Dokumentation oder Pull Requests in der REST-API-Dokumentation.

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.

Du kannst beispielsweise einen Workflow ausführen, wenn ein Pull Request geöffnet oder erneut geöffnet wurde.

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.

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

Dieser Workflow wird beispielsweise ausgeführt, wenn jemand einen Pull Request öffnet, der auf einen Branch abzielt, dessen Name mit releases/ beginnt:

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, für einen Branch geöffnet wird, dessen Name mit releases/ beginnt:

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:

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

Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request eine Änderung an einer JavaScript-Datei (.js) enthält:

on:
  pull_request:
    paths:
      - '**.js'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, für einen Branch geöffnet wird, dessen Name mit releases/ beginnt:

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Ausführen des Workflows beim Zusammenführen eines Pull Requests

Beim Zusammenführen eines Pull Requests wird der Pull Request automatisch geschlossen. Zur Ausführung eines Workflows beim Zusammenführen eines Pull Requests verwendest du 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.

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 findest du unter Authenticating with the GITHUB_TOKEN („Authentifizieren mit dem GITHUB_TOKEN“).

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Server 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.

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 unterAktivieren von Workflows für Forks privater Repositorys.

Hinweis: 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 (issue_comment verwenden)

Verwende das Ereignis issue_comment, um den Workflow auszuführen, wenn ein Kommentar zu einem Pull Request (nicht zu einem Pull-Request-Diff) erstellt, bearbeitet oder gelöscht wird. Verwende für Aktivitäten im Zusammenhang mit Pull-Request-Überprüfungen oder Pull-Request-Überprüfungskommentaren die Ereignisse pull_request_review oder pull_request_review_comment.

pull_request_review

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

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. Verwende für Aktivitäten im Zusammenhang mit Pull-Request-Überprüfungskommentaren oder Pull-Request-Kommentaren stattdessen die Ereignisse pull_request_review_comment oder issue_comment. Informationen zu den Pull-Request-Überprüfungs-APIs findest du unter PullRequestReview in der GraphQL-API-Dokumentation oder Pull-Request-Überprüfungen in der REST-API-Dokumentation.

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

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:

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 findest du unter Authenticating with the GITHUB_TOKEN („Authentifizieren mit dem GITHUB_TOKEN“).

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Server 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.

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 unterAktivieren von Workflows für Forks privater Repositorys.

Hinweis: 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

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

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

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. Verwende für Aktivitäten im Zusammenhang mit Pull-Request-Überprüfungen oder Pull-Request-Kommentaren stattdessen die Ereignisse pull_request_review oder issue_comment. Informationen zu den Pull-Request-Überprüfungskommentar-APIs findest du unter PullRequestReviewComment in der GraphQL-API-Dokumentation oder Überprüfungskommentare in der REST-API-Dokumentation.

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

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 findest du unter Authenticating with the GITHUB_TOKEN („Authentifizieren mit dem GITHUB_TOKEN“).

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Server 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.

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 unterAktivieren von Workflows für Forks privater Repositorys.

Hinweis: 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

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 Commit für den PR-BasisbranchPR-Basisbranch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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.

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 Basis des Pull Requests ausgeführt, anstatt im Kontext des Merge-Commits, wie dies beim pull_request-Ereignis der Fall ist. 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.

Warnung: Für Workflows, die vom Ereignis pull_request_target ausgelöst werden, wird GITHUB_TOKEN die Berechtigung zum Lesen/Schreiben des Repositorys gewährt, es sei denn, der Schlüssel permissions wird angegeben, und der Workflow kann auf Geheimnisse zugreifen, auch wenn er von einer Kopie ausgelöst wird. Obwohl der Workflow im Kontext der Basis des Pull Requests ausgeführt wird, solltest du sicherstellen, dass du mit diesem Ereignis keinen nicht vertrauenswürdigen Code aus dem Pull Request auscheckst, erstellst oder ausführst. Darüber hinaus teilen alle Caches denselben Bereich wie der Basisbranch. Damit Cachepoisoning verhindert wird, solltest du den Cache nicht speichern, wenn die Möglichkeit besteht, dass der Cacheinhalt geändert wurde. Weitere Informationen findest du unter Keeping your GitHub Actions and workflows secure: Preventing pwn requests auf der GitHub Security Lab-Website.

Du kannst beispielsweise einen Workflow 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]

Ausführen des 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.

Dieser Workflow wird beispielsweise ausgeführt, wenn jemand einen Pull Request öffnet, der auf einen Branch abzielt, dessen Name mit releases/ beginnt:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, für einen Branch geöffnet wird, dessen Name mit releases/ beginnt:

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:

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

Dieser Workflow wird beispielsweise ausgeführt, wenn ein Pull Request eine Änderung an einer JavaScript-Datei (.js) enthält:

on:
  pull_request_target:
    paths:
      - '**.js'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, für einen Branch geöffnet wird, dessen Name mit releases/ beginnt:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Ausführen des Workflows beim Zusammenführen eines Pull Requests

Beim Zusammenführen eines Pull Requests wird der Pull Request automatisch geschlossen. Zur Ausführung eines Workflows beim Zusammenführen eines Pull Requests verwendest du 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.

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
pushNicht zutreffendWenn du einen Branch löschst, wird der SHA in der Workflowausführung (einschließlich der zugehörigen Refs) auf den Standardbranch des Repositorys zurückgesetzt.Aktualisierter Ref

Hinweis: Die für GitHub Actions verfügbare Webhook-Nutzlast umfasst nicht die Attribute added, removed und modified im commit-Objekt. Du kannst das vollständige Commitobjekt mithilfe der API abrufen. Informationen findest du unter Commit in der GraphQL-API-Dokumentation oder Abrufen eines Commits in der REST-API-Dokumentation.

Hinweis: Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags gleichzeitig pushst.

Führt deinen Workflow aus, wenn du einen Commit oder Tag pushst.

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

on:
  push

Hinweis: Wenn ein push-Webhookereignis eine Workflowausführung auslöst, zeigt das Feld „Push durch“ der Benutzeroberfläche von GitHub Actions das Konto des Pushers und nicht den Autor oder Committer an. 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.

Dieser Workflow wird z. B. ausgeführt, wenn ein Push an main oder an einen Branch stattfindet, der mit releases/ beginnt.

on:
  push:
    branches:
      - 'main'
      - 'releases/**'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, an einen Branch stattfindet, dessen Name mit releases/ beginnt:

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.

Dieser Workflow wird z. B. ausgeführt, wenn ein Tag gepusht wird, das mit v1. beginnt.

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.

Dieser Workflow wird beispielsweise ausgeführt, wenn eine Änderung an eine JavaScript-Datei (.js) gepusht wird:

on:
  push:
    paths:
      - '**.js'

Hinweis: 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 einer JavaScript-Datei (.js) enthält, an einen Branch stattfindet, dessen Name mit releases/ beginnt:

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
registry_package- published
- updated
Commit des veröffentlichten PaketsBranch oder Tag des veröffentlichten Pakets

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn Aktivitäten im Zusammenhang mit GitHub Packages in deinem Repository stattfinden. Weitere Informationen findest du in der GitHub Packages-Dokumentation.

Du kannst z. B. einen Workflow ausführen, wenn eine neue Paketversion veröffentlicht (published) wurde.

on:
  registry_package:
    types: [published]

release

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
release- published
- unpublished
- created
- edited
- deleted
- prereleased
- released
Letzter Commit in dem bezeichneten ReleaseTag-Ref des Release refs/tags/<tag_name>

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Workflows werden für die Aktivitätstypen created, edited oder deleted für Release-Entwürfe nicht ausgelöst. Wenn du dein Release über die GitHub Enterprise Server-Browser-UI erstellst, wird es möglicherweise automatisch als Entwurf gespeichert.

Hinweis: Der Typ prereleased löst nicht für Vorab-Releases aus, die aus Release-Entwürfen veröffentlicht wurden, aber der published-Typ löst aus. 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 zu den Release-APIs findest du unter Release in der GraphQL-API-Dokumentation oder Releases in der REST-API-Dokumentation.

Du kannst z. B. einen Workflow ausführen, wenn ein Release veröffentlicht (published) wurde.

on:
  release:
    types: [published]

repository_dispatch

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
repository_dispatchBenutzerdefiniertLetzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Du kannst die GitHub Enterprise Server-API verwenden, um ein Webhook-Ereignis namens repository_dispatch auszulösen, wenn du einen Workflow für Aktivitäten auslösen möchtest, die außerhalb von GitHub Enterprise Server stattfinden. Weitere Informationen findest du unter Erstellen eines Repository-Versandereignisses.

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 die Ausführung eines Workflows aus. Du kannst das Schlüsselwort types verwenden, damit der Workflow nur ausgeführt wird, wenn ein bestimmter event_type-Wert in der Webhook-Nutzlast repository_dispatch gesendet wird.

on:
  repository_dispatch:
    types: [on-demand-test]

Hinweis: Der event_type-Wert ist auf 100 Zeichen beschränkt.

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:

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

kannst du auf die Nutzlast in einem Workflow wie folgt zugreifen:

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

schedule

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: 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. Um die Wahrscheinlichkeit einer Verzögerung zu verringern, kannst du deinen Workflow so planen, dass er zu einer anderen Uhrzeit ausgeführt wird.

Mit dem schedule-Ereignis kannst du einen Workflow zu einem geplanten Zeitpunkt auslösen.

Mithilfe der POSIX-Cron-Syntax kannst du einen Workflow 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 Du geplante Workflows ausführen kannst, ist einmal alle 5 Minuten.

In diesem Beispiel wird der Workflow jeden Tag um 5:30 Uhr und 17:30 Uhr UTC ausgelöst:

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

Ein einzelner Workflow kann durch mehrere schedule-Ereignisse ausgelöst werden. Über den Kontext github.event.schedule kannst du auf das Zeitplanereignis zugreifen, das den Workflow ausgelöst hat. In diesem Beispiel wird der Workflow von Montag bis Donnerstag um 5:30 Uhr UTC gestartet, wobei der Schritt Not on Monday or Wednesday am Montag und Mittwoch übersprungen wird.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 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"

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

┌───────────── 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)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

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

OperatorBESCHREIBUNGBeispiel
*Beliebiger Wert15 * * * * wird jede 15. Minute jeder Stunde jedes Tages ausgeführt.
,Trennzeichen in Werteliste2,10 4,5 * * * wird in der 2. und 10. Minute der 4. und 5. Stunde jedes Tages ausgeführt.
-Wertebereich30 4-6 * * * wird in der 30. Minute der 4., 5. und 6. Stunde ausgeführt.
/Schrittwerte20/15 * * * * wird alle 15 Minuten ab der 20. bis zur 59. Minute ausgeführt (20., 35. und 50. Minute).

Hinweis: GitHub Actions unterstützt nicht die nicht normgerechte Syntax @yearly, @monthly, @weekly, @daily, @hourly und @reboot.

Du kannst 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 bereit.

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 Workflowausführungen.

status

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
statusLetzter Commit an Standard-Branch

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

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 weitere Details zur Statusänderung angeben möchtest, solltest du das Ereignis check_run verwenden. Informationen zu den Commitstatus-APIs findest du unter Status in der GraphQL-API-Dokumentation oder Status in der REST-API-Dokumentation.

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

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.

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

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
watch- startedLetzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der Aktivitätstyp started unterstützt wird, bleibt dein Workflow durch Angabe des Aktivitätstyps spezifisch, wenn zukünftig weitere Aktivitätstypen hinzugefügt werden. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Führt deinen Workflow aus, wenn das Repository des Workflows markiert ist. Informationen zu den Pull-Request-APIs findest du unter addStar in der GraphQL-API-Dokumentation oder Versehen mit einem Stern in der REST-API-Dokumentation.

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.

on:
  watch:
    types: [started]

workflow_call

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Identisch mit dem AufruferworkflowNicht zutreffendIdentisch mit dem AufruferworkflowIdentisch mit dem Aufruferworkflow

workflow_call wird verwendet, um anzugeben, dass ein Workflow von einem anderen Workflow aufgerufen werden kann. Wenn ein Workflow mit dem workflow_call-Ereignis ausgelöst wird, ist die Ereignisnutzlast im aufgerufenen Workflow die gleiche Ereignisnutzlast aus dem aufrufenden Workflow. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Im folgenden Beispiel wird der Workflow nur ausgeführt, wenn er aus einem anderen Workflow aufgerufen wird:

on: workflow_call

workflow_dispatch

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
workflow_dispatchLetzter Commit für den GITHUB_REF-Branch oder -TagBranch oder Tag, der den Versand empfangen hat

Wenn du einen Workflow manuell auslösen möchtest, verwende das Ereignis workflow_dispatch. Du kannst die Ausführung eines Workflows manuell mit der GitHub Enterprise Server-API, GitHub CLI oder GitHub Enterprise Server-Browserschnittstelle auslösen. Weitere Informationen findest du unter Manuelles Ausführen eines Workflows.

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 github.event.inputs-Kontext zugreifen. Weitere Informationen findest du unter Kontexte.

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 druckt die Werte dann mit den Kontexteigenschaften github.event.inputs.logLevel,github.event.inputs.tags und github.event.inputs.environment in das Protokoll.

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: ${{ github.event.inputs.logLevel }}
          TAGS: ${{ github.event.inputs.tags }}
          ENVIRONMENT: ${{ github.event.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.

Eingaben für einen Workflow

Du kannst auch Eingaben übergeben, wenn du einen Workflow aus einem Skript ausführst oder GitHub CLI verwendest. Beispiel:

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

Weitere Informationen findest du in den GitHub CLI-Informationen in Manuelles Ausführen eines Workflows.

workflow_run

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
workflow_run- completed
- requested
Letzter Commit an Standard-BranchStandard-Branch

Hinweis: Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Der Aktivitätstyp requested tritt nicht ein, wenn ein Workflow erneut ausgeführt wird. Informationen zu jedem Aktivitätstyp findest du unter Webhook-Ereignisse und Nutzlasten. 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 findest du unter Workflowsyntax für GitHub Actions.

Hinweis: Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn sich die Workflowdatei im Standardbranch befindet.

Hinweis: Du kannst workflow_run nicht verwenden, um eine Kette aus mehr als drei Workflowebenen zu bilden. 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. ABCDEF), 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.

In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate Workflow „Tests ausführen“ abgeschlossen ist.

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.

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:

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. Beispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens Build in einem Branch namens canary ausgeführt wird.

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

Verwenden von Daten aus dem auslösenden Workflow

Du kannst auf die workflow_run-Ereignisnutzlast zugreifen, die 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.)

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@v3
        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 Kontext github.event.workflow_run und die GitHub Enterprise Server-REST-API, um das Artefakt herunterzuladen, das vom obigen Workflow hochgeladen wurde, entzippt das heruntergeladene Artefakt und kommentiert den Pull Request, dessen Nummer als Artefakt hochgeladen wurde.

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v6
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });