Skip to main content

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 Cloud stattfindet oder ein Ereignis außerhalb von GitHub Enterprise Cloud 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.

Einige Ereignisse weisen mehrere Aktivitätstypen auf. Für diese Ereignisse kannst du angeben, welche Aktivitätstypen eine Workflowausführung auslösen. Weitere Informationen zur Bedeutung der einzelnen Aktivitätstypen findest du unter Webhook-Ereignisse und -Nutzlasten.

Note

Nicht alle Webhookereignisse lösen Workflows aus.

branch_protection_rule

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 Branchschutzregeln findest du unter Informationen zu geschützten Branches. Informationen zu den Branchschutzregel-APIs finden Sie unter Objects in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Branches und deren Einstellungen.

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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. Informationen findest du unter Verwenden der REST-API zur Interaktion mit Überprüfungen. Informationen zu den APIs zur Überprüfungsausführung finden Sie unter Objects in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Überprüfungsausführungen.

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen findest du unter „Webhook-Ereignisse und -Nutzlasten“. Obwohl nur der Aktivitätstyp completed unterstützt wird, bleibt dein Workflow durch Angabe des Aktivitätstyps spezifisch, wenn zukünftig weitere Aktivitätstypen hinzugefügt werden. Standardmäßig lösen alle Aktivitätstypen Workflows aus, die auf diesem Ereignis ausgeführt werden. Mit Schlüsselwort types kannst du die Workflowausführungen auf bestimmte Aktivitätstypen begrenzen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Note

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

Note

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. Informationen findest du unter Verwenden der REST-API zur Interaktion mit Überprüfungen. Informationen zu den Überprüfungssammlungs-APIs finden Sie unter Objects in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Prüfsuiten.

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 verfügbarLetzter Commit im erstellten Branch oder TagErstellter Branch oder Tag

Note

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 finden Sie unter Mutationen in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Git-Verweise.

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

on:
  create

delete

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deleteNicht verfügbarLetzter Commit an Standard-BranchStandard-Branch

Note

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

Note

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 finden Sie unter Mutationen in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Git-Verweise.

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

on:
  delete

deployment

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deploymentNicht verfügbarBereitzustellender 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 Mutationen in der GraphQL-API-Dokumentation oder unter „REST-API-Endpunkte für Repositorys“.

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

on:
  deployment

deployment_status

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
deployment_statusNicht verfügbarBereitzustellender CommitBereitzustellender Branch oder Tag (leer bei Commit)

Note

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 von Bereitstellungsstatus finden Sie unter „Mutationen“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Bereitstellungen“.

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

on:
  deployment_status

discussion

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
discussion- created
- edited
- deleted
- transferred
- pinned
- unpinned
- labeled
- unlabeled
- locked
- unlocked
- category_changed
- answered
- unanswered
Letzter Commit an Standard-BranchStandard-Branch

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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

Note

Webhookereignisse für GitHub Discussions sind derzeit als public preview verfügbar. Änderungen sind vorbehalten.

Führt deinen Workflow aus, wenn eine Diskussion im Repository des Workflows erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Kommentaren zu einer Diskussion das Ereignis discussion_comment. Weitere Informationen zu Diskussionen findest du unter Informationen zu Diskussionen. Informationen zur GraphQL-API findest du unter Objects.

Du kannst beispielsweise einen Workflow ausführen, wenn eine Diskussion erstellt (created), bearbeitet (edited) oder beantwortet (answered) wurde.

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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

Note

Webhookereignisse für GitHub Discussions sind derzeit als public preview verfügbar. Änderungen sind vorbehalten.

Führt deinen Workflow aus, wenn ein Kommentar zu einer Diskussion im Repository des Workflows erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit einer Diskussion im Gegensatz zu Kommentaren zu der Diskussion das Ereignis discussion. Weitere Informationen zu Diskussionen findest du unter Informationen zu Diskussionen. Informationen zur GraphQL-API findest du unter Objects.

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

on:
  discussion_comment:
    types: [created, deleted]

fork

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
forkNicht verfügbarLetzter Commit an Standard-BranchStandard-Branch

Note

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 REST-API-Endpunkte für forken.

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

on:
  fork

gollum

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
gollumNicht verfügbarLetzter Commit an Standard-BranchStandard-Branch

Note

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 Issuekommentar-APIs findest du unter Objects in der GraphQL-API-Dokumentation oder unter Webhook-Ereignisse und -Nutzlasten 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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 finden Sie unter „Objects“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Issues“.

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 finden Sie unter „Objects“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Bezeichnungen“.

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]

merge_group

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
merge_groupchecks_requestedSHA der MergegruppeRef der Mergegruppe

Note

  • Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der checks_requested-Aktivitätstyp unterstützt wird, bleibt dein Workflow durch Angabe des Aktivitätstyps spezifisch, wenn zukünftig weitere Aktivitätstypen hinzugefügt werden. Informationen zu den einzelnen Aktivitätstypen 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.
  • Wenn Ihr Repository GitHub Actions verwendet, um erforderliche Prüfungen durchzuführen, oder wenn Sie Workflows über Organisationsregelsätze für Pull Requests in Ihrem Repository benötigen, müssen Sie die Workflows aktualisieren, um das merge_group Ereignis als zusätzlichen Auslöser einzubeziehen. Andernfalls werden Statusüberprüfungen nicht ausgelöst, wenn du einer Mergewarteschlange einen Pull Request hinzufügst. Der Merge ist nicht erfolgreich, da die erforderliche Statusüberprüfung nicht gemeldet wird. Das merge_group-Ereignis ist von den Ereignissen pull_request und push getrennt.

Führt deinen Workflow aus, wenn einer Mergewarteschlange ein Pull Request hinzugefügt wird, die den Pull Request wiederum einer Mergegruppe hinzufügt. Weitere Informationen findest du unter Zusammenführen eines Pull Requests mit einer Mergewarteschlange.

Du kannst beispielsweise einen Workflow ausführen, wenn die Aktivität checks_requested eingetreten ist.

on:
  pull_request:
    branches: [ "main" ]
  merge_group:
    types: [checks_requested]

milestone

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 finden Sie unter „Objects“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Meilensteine“.

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_buildNicht verfügbarLetzter Commit an Standard-BranchNicht verfügbar

Note

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 Eine Veröffentlichungsquelle für deine GitHub Pages-Website konfigurieren. Informationen zur REST-API findest du unter REST-API-Endpunkte für Repositorys.

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

on:
  page_build

public

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
publicNicht verfügbarLetzter Commit an Standard-BranchStandard-Branch

Note

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 REST-API-Endpunkte für 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
- locked
- unlocked
- enqueued
- dequeued
- milestoned
- demilestoned
- ready_for_review
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
Letzter Merge-Commit im Branch GITHUB_REFPR-Mergebranch refs/pull/PULL_REQUEST_NUMBER/merge

Note

  • Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.
  • 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 finden Sie unter pull_request_target.
  • Die pull_request-Webhook-Ereignisnutzdaten ist für zusammengeführte Pull Requests und Pull Requests leer, die aus verzweigten Repositorys stammen.
  • Der Wert GITHUB_REF variiert für eine geschlossene Pullanforderung, je nachdem, ob die Pullanforderung zusammengeführt wurde oder nicht. Wenn eine Pullanforderung geschlossen, aber nicht zusammengeführt wurde, lautet sie refs/pull/PULL_REQUEST_NUMBER/merge. Wenn eine Pullanforderung als Ergebnis der Zusammenführung geschlossen wurde, ist sie die vollqualifizierte ref der Verzweigung, mit der sie zusammengeführt wurde, z. B. /refs/heads/main.

Führt deinen Workflow aus, wenn Aktivitäten für einen Pull Request im Repository des Workflows stattfinden. Wenn beispielsweise keine Aktivitätstypen angegeben werden, wird der Workflow ausgeführt, wenn ein Pull Request geöffnet oder erneut geöffnet wird oder wenn der Headbranch des Pull Requests aktualisiert wird. 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 finden Sie unter Objects in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Pullanforderungen.

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 pull_request-Workflows basierend auf dem Head- oder Basisbranch eines Pull Requests

Du kannst den Workflow mithilfe des Filters branches oder branches-ignore so konfigurieren, dass er nur für Pull Requests ausgeführt wird, die auf bestimmte Branches abzielen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

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/**'

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull Request, der eine Änderung 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 des pull_request-Workflows basierend auf Dateien, die in einem Pull Request geändert wurden

Du kannst deinen Workflow auch so konfigurieren, dass er ausgeführt wird, wenn ein Pull Request bestimmte Dateien ändert. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

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

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

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull Request, der eine Änderung 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 pull_request-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 Automatische Tokenauthentifizierung.

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Cloud die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen findest du unter Genehmigen von Workflowausführungen über öffentliche Forks.

Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unterVerwalten von GitHub Actions-Einstellungen für ein Repository.

Note

Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.

pull_request_comment (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/PULL_REQUEST_NUMBER/merge

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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-Review-APIs finden Sie unter „Objects“ in der GraphQL-API-Dokumentation oder unter „REST-API-Endpunkte für Pullanforderungen.“

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

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Cloud die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen findest du unter Genehmigen von Workflowausführungen über öffentliche Forks.

Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unterVerwalten von GitHub Actions-Einstellungen für ein Repository.

Note

Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.

pull_request_review_comment

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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 finden Sie unter „Objects“ in der GraphQL-API-Dokumentation oder unter „REST-API-Endpunkte für Pullanforderungen.“

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

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub Enterprise Cloud die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

Wenn ein Mitwirkender zum ersten Mal einen Pull Request an ein öffentliches Repository sendet, muss ein Verwalter mit Schreibzugriff möglicherweise die Ausführung von Workflows im Pull Request genehmigen. Weitere Informationen findest du unter Genehmigen von Workflowausführungen über öffentliche Forks.

Bei Pull Requests aus einem geforkten Repository für ein privates Repository werden Workflows nur ausgeführt, wenn sie aktiviert sind. Weitere Informationen findest du unterVerwalten von GitHub Actions-Einstellungen für ein Repository.

Note

Workflows, die von Dependabot-Pull Requests ausgelöst wurden, werden behandelt, als wenn sie aus einem geforkten Repository stammen, sodass auch für sie diese Einschränkungen gelten.

pull_request_target

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Warning

Bei Workflows, die vom Ereignis pull_request_target ausgelöst werden, wird GITHUB_TOKEN die Berechtigung zum Lesen/Schreiben im Repositorys gewährt – es sei denn, der Schlüssel permissions wird angegeben, und der Workflow kann auf Geheimnisse zugreifen, auch wenn er von einem Fork 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 pull_request_target-Workflows basierend auf dem Head- oder Basisbranch eines Pull Requests

Du kannst den Workflow mithilfe des Filters branches oder branches-ignore so konfigurieren, dass er nur für Pull Requests ausgeführt wird, die auf bestimmte Branches abzielen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

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/**'

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull Request, der eine Änderung 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_target:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Ausführen des pull_request_target-Workflows basierend auf Dateien, die in einem Pull Request geändert wurden

Du kannst den Filter paths oder paths-ignore verwenden, um deinen Workflow so zu konfigurieren, dass er ausgeführt wird, wenn ein Pull Request bestimmte Dateien ändert. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

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'

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Pull Request, der eine Änderung 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 pull_request_target-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 zutreffendSpitzen-Commit wird an den Ref gepusht. Wenn Sie einen Branch löschen, wird der SHA in der Workflowausführung (einschließlich der zugehörigen Refs) auf den Standardbranch des Repositorys zurückgesetzt.Aktualisierter Ref

Note

Die für GitHub Actions verfügbare Webhooknutzlast umfasst nicht die Attribute added, removed und modified im commit-Objekt. Du kannst das vollständige Commitobjekt mithilfe der API abrufen. Informationen finden Sie unter „Objects“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Commits“.

Note

Ereignisse werden nicht erstellt, wenn mehr als 5.000 Branches gleichzeitig verschoben werden. Hinweis: Ein Ereignis wird nicht erstellt, wenn Sie mehr als drei Tags gleichzeitig pushen.

Führt den Workflow aus, wenn ein Commit oder Tag übertragen oder ein Repository geklont wird.

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

on:
  push

Note

Wenn ein push-Webhookereignis eine Workflowausführung auslöst, zeigt das Feld „pushed by“ 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/**'

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Push, der eine Änderung 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'

Note

Wenn du sowohl den branches-Filter als auch den paths-Filter verwendest, wird der Workflow nur dann ausgeführt, wenn beide Filter erfüllt sind. Der folgende Workflow wird beispielsweise nur ausgeführt, wenn ein Push, der eine Änderung 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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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

Note

Beim Pushen von Containerimages für mehrere Architekturen tritt dieses Ereignis einmal pro Manifest auf, sodass du möglicherweise feststellst, dass dein Workflow mehrmals ausgelöst wird. Verwende eine Bedingung, um dieses Phänomen zu minimieren und den Workflowauftrag nur für das Ereignis auszuführen, das die tatsächlichen Imagetaginformationen enthält:

jobs:
    job_name:
        if: $true

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>

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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

Note

Der Typ prereleased löst nicht für Vorabversionen aus, die aus Entwurfsversionen 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 Objects in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte für Releases und Releaseressourcen 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

Note

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

Du kannst die GitHub Enterprise Cloud-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 Cloud stattfinden. Weitere Informationen findest du unter REST-API-Endpunkte für Repositorys.

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: [test_result]

Note

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

Note

  • Die maximale Anzahl von Eigenschaften auf oberster Ebene in client_payload beträgt 10.
  • Die Nutzdaten dürfen maximal 65.535 Zeichen enthalten.

schedule

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
Nicht verfügbarNicht verfügbarLetzter Commit an Standard-BranchStandard-Branch

Note

  • Das Ereignis schedule kann sich in Phasen mit einer hohen Auslastung durch GitHub Actions-Workflowausführungen verzögern. Eine hohe Last ist unter anderem zu Beginn jeder Stunde zu verzeichnen. Wenn die Auslastung ausreichend hoch ist, werden einige Aufträge in der Warteschlange möglicherweise gelöscht. Um die Wahrscheinlichkeit einer Verzögerung zu verringern, kannst du deinen Workflow so planen, dass er zu einer anderen Uhrzeit ausgeführt wird.

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

  • Geplante Workflows werden nur auf dem Standardbranch ausgeführt.

  • In einem öffentlichen Repository werden geplante Workflows automatisch deaktiviert, wenn in 60 Tagen keine Repositoryaktivität aufgetreten ist. Informationen zur Wiederaktivierung eines deaktivierten Workflows finden Sie unter „Deaktivieren und Aktivieren eines Workflows.“

  • Wenn der letzte Benutzer, der im Cron-Zeitplan eines Workflows festgeschrieben werden soll, aus der Organisation entfernt wird, wird der geplante Workflow deaktiviert. Wenn ein Benutzer mit writeBerechtigungen für das Repository eine Übergabe vornimmt, die den Cron-Zeitplan ändert, wird der geplante Workflow wieder aktiviert. Beachten Sie, dass der Workflow in dieser Situation nicht durch eine Änderung der Workflowdatei reaktiviert wird; Sie müssen den cron-Wert ändern und diese Änderung übernehmen.

    Beispiel:

    on:
      schedule:
        - cron: "15 4,5 * * *"   # <=== Change this value
    

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 in jeder 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).

Note

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 Workflow-Läufe.

status

Nutzlast des Webhook-EreignissesAktivitätstypenGITHUB_SHAGITHUB_REF
statusNicht verfügbarLetzter Commit an Standard-BranchNicht verfügbar

Note

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 finden Sie unter „Objects“ in der Dokumentation zur GraphQL-API oder unter „REST-API-Endpunkte für Commits“.

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der started-Aktivitätstyp unterstützt wird, bleibt dein Workflow durch Angabe des Aktivitätstyps spezifisch, wenn zukünftig weitere Aktivitätstypen hinzugefügt werden. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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 finden Sie unter Mutationen in der GraphQL-API-Dokumentation oder unter REST-API-Endpunkte zum Versehen mit einem Stern.

Sie können 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 verfügbarIdentisch 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_dispatchNicht verfügbarLetzter Commit für den GITHUB_REF-Branch oder -TagBranch oder Tag, der den Versand empfangen hat

Note

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

Damit ein Workflow manuell ausgelöst werden kann, musst du das workflow_dispatch-Ereignis konfigurieren. Du kannst die Ausführung eines Workflows manuell mit der GitHub Enterprise Cloud-API, GitHub CLI oder GitHub Enterprise Cloud-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 inputs-Kontext zugreifen. Weitere Informationen findest du unter Zugreifen auf kontextbezogene Informationen zu Workflowausführungen.

Note

  • Der Workflow empfängt auch die Eingaben im github.event.inputs-Kontext. Die Informationen im Kontext inputs und github.event.inputs sind identisch, außer dass der Kontext inputs boolesche Werte als solche beibehält, anstatt sie in Zeichenfolgen zu konvertieren. Der Typ choice wird in eine Zeichenfolge aufgelöst und ist eine einzelne auswählbare Option.
  • Die maximale Anzahl von Eigenschaften auf oberster Ebene für inputs beträgt 10.
  • Die maximale Länge der Nutzdaten für inputs beträgt 65.535 Zeichen.

In diesem Beispiel werden Eingaben namens logLevel, tags und environment definiert. Du übergibst Werte für diese Eingaben an den Workflow, wenn du ihn ausführst. Dieser Workflow gibt dann die Werte mit den Kontexteigenschaften inputs.logLevel, inputs.tags und inputs.environment in das Protokoll aus.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

Wenn du diesen Workflow über einen Browser ausführst, musst du Werte für die erforderlichen Eingaben manuell eingeben, bevor der Workflow ausgeführt wird.

Screenshot: Liste mit Workflowausführungen Ein Dropdownmenü mit der Bezeichnung „Workflow ausführen“, das erweitert ist und dunkelorange umrissene Eingabefelder enthält.

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 unter Manuelles Ausführen eines Workflows.

workflow_run

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

Note

Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Der Aktivitätstyp requested tritt nicht auf, wenn ein Workflow erneut ausgeführt wird. Informationen zu den einzelnen Aktivitätstypen 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.

Note

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

Note

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@v4
        with:
          name: pr_number
          path: pr/

Wenn eine Ausführung des obigen Workflows abgeschlossen ist, löst sie eine Ausführung des folgenden Workflows aus. Der folgende Workflow verwendet den Kontext github.event.workflow_run und die GitHub Enterprise Cloud-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!'
            });