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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
branch_protection_rule | - created - edited - deleted | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_run | - created - rerequested - completed - requested_action | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_suite | - completed | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
create | Nicht verfügbar | Letzter Commit im erstellten Branch oder Tag | Erstellter Branch oder Tag |
Note
Ein Ereignis wird nicht erstellt, wenn du mehr als drei Tags 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
delete | Nicht verfügbar | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment | Nicht verfügbar | Bereitzustellender Commit | Bereitzustellender Branch oder bereitzustellendes Tag (leer, wenn mit einem Commit-SHA erstellt) |
Führt deinen Workflow aus, wenn eine Bereitstellung im Repository des Workflows erstellt wird. Bereitstellungen, die mit einem Commit-SHA erstellt wurden, verfügen möglicherweise nicht über 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment_status | Nicht verfügbar | Bereitzustellender Commit | Bereitzustellender 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
discussion | - created - edited - deleted - transferred - pinned - unpinned - labeled - unlabeled - locked - unlocked - category_changed - answered - unanswered | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
discussion_comment | - created - edited - deleted | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
fork | Nicht verfügbar | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
gollum | Nicht verfügbar | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
issue_comment | - created - edited - deleted | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
issues | - opened - edited - deleted - transferred - pinned - unpinned - closed - reopened - assigned - unassigned - labeled - unlabeled - locked - unlocked - milestoned - demilestoned | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
label | - created - edited - deleted | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
merge_group | checks_requested | SHA der Mergegruppe | Ref der Mergegruppe |
Note
- Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Obwohl nur der
checks_requested
-Aktivitätstyp unterstützt wird, 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üsselworttypes
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. Dasmerge_group
-Ereignis ist von den Ereignissenpull_request
undpush
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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
milestone | - created - closed - opened - edited - deleted | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
page_build | Nicht verfügbar | Letzter Commit an Standard-Branch | Nicht 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
public | Nicht verfügbar | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_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_REF | PR-Mergebranch refs/pull/PULL_REQUEST_NUMBER/merge |
Note
- Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen findest du unter „Webhook-Ereignisse und -Nutzlasten“. Standardmäßig wird ein Workflow nur ausgeführt, wenn der Aktivitätstyp eines
pull_request
-Ereignissesopened
,synchronize
oderreopened
ist. Verwende das Schlüsselworttypes
, 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 Ereignispull_request_target
ausgeführt, auch wenn der Pull Request einen Mergekonflikt aufweist. Bevor du den Triggerpull_request_target
verwendest, solltest du dich der Sicherheitsrisiken bewusst sein. Weitere Informationen finden Sie unterpull_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 sierefs/pull/PULL_REQUEST_NUMBER/merge
. Wenn eine Pullanforderung als Ergebnis der Zusammenführung geschlossen wurde, ist sie die vollqualifizierteref
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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review | - submitted - edited - dismissed | Letzter Merge-Commit im Branch GITHUB_REF | PR-Mergebranch refs/pull/PULL_REQUEST_NUMBER/merge |
Note
Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review_comment | - created - edited - deleted | Letzter Merge-Commit im Branch GITHUB_REF | PR-Mergebranch refs/pull/PULL_REQUEST_NUMBER/merge |
Note
Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request | - assigned - unassigned - labeled - unlabeled - opened - edited - closed - reopened - synchronize - converted_to_draft - ready_for_review - locked - unlocked - review_requested - review_request_removed - auto_merge_enabled - auto_merge_disabled | Letzter Commit für den PR-Basisbranch | PR-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
push | Nicht zutreffend | Spitzen-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
registry_package | - published - updated | Commit des veröffentlichten Pakets | Branch oder Tag des veröffentlichten Pakets |
Note
Dieses Ereignis wird von mehreren Aktivitätstypen ausgelöst. Informationen zu den einzelnen Aktivitätstypen 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
release | - published - unpublished - created - edited - deleted - prereleased - released | Letzter Commit in dem bezeichneten Release | Tag-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
repository_dispatch | Benutzerdefiniert | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Nicht verfügbar | Nicht verfügbar | Letzter Commit an Standard-Branch | Standard-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
write
Berechtigungen 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 dencron
-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:
Operator | Beschreibung | Beispiel |
---|---|---|
* | Beliebiger Wert | 15 * * * * wird in jeder 15. Minute jeder Stunde jedes Tages ausgeführt. |
, | Trennzeichen in Werteliste | 2,10 4,5 * * * wird in der 2. und 10. Minute der 4. und 5. Stunde jedes Tages ausgeführt. |
- | Wertebereich | 30 4-6 * * * wird in der 30. Minute der 4., 5. und 6. Stunde ausgeführt. |
/ | Schrittwerte | 20/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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
status | Nicht verfügbar | Letzter Commit an Standard-Branch | Nicht 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
watch | - started | Letzter Commit an Standard-Branch | Standard-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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Identisch mit dem Aufruferworkflow | Nicht verfügbar | Identisch mit dem Aufruferworkflow | Identisch mit dem Aufruferworkflow |
workflow_call
wird verwendet, um 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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_dispatch | Nicht verfügbar | Letzter Commit für den GITHUB_REF -Branch oder -Tag | Branch oder Tag, der den Versand empfangen hat |
Note
Dieses Ereignis löst nur dann eine Workflowausführung aus, wenn 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 Kontextinputs
undgithub.event.inputs
sind identisch, außer dass der Kontextinputs
boolesche Werte als solche beibehält, anstatt sie in Zeichenfolgen zu konvertieren. Der Typchoice
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.
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-Ereignisses | Aktivitätstypen | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_run | - completed - requested - in_progress | Letzter Commit an Standard-Branch | Standard-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. A
→ B
→ C
→ D
→ E
→ F
), werden die Workflows E
und F
nicht ausgeführt.
Dieses Ereignis tritt auf, wenn eine Workflowausführung angefordert oder abgeschlossen wird. Es ermöglicht dir, einen Workflow basierend auf der Ausführung oder Fertigstellung eines anderen Workflows auszuführen. Der vom Ereignis workflow_run
gestartete Workflow kann auf Geheimnisse und Schreibtoken zugreifen, auch wenn der vorherige Workflow nicht dazu in der Lage war. Dies ist in Fällen nützlich, in denen der vorherige Workflow absichtlich nicht privilegiert ist, du aber eine privilegierte Aktion in einem späteren Workflow ausführen musst.
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!'
});