Ereignisse zum Auslösen von Workflows

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.

branch_protection_rule

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

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

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

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

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

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

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

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

on:
  deployment_status

discussion

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

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

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

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

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

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

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]

milestone

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

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

project

Führt den Workflow aus, wenn ein Projekt (klassisch) erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Karten oder Spalten in einem Projekt (klassisch) stattdessen die Ereignisse project_card oder project_column. Weitere Informationen zu Projekte (klassisch) findest du unter Informationen zu projects (classic). Informationen zu den Projekt (klassisch)-APIs finden Sie unter „Objects“ in der GraphQL-API-Dokumentation oder unter „REST-API zum Verwalten von Projects (classic).“

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

on:
  project:
    types: [created, deleted]

project_card

Führt deinen Workflow aus, wenn eine Karte auf einem Projekt (klassisch) erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Projekte (klassisch) oder Spalten in einem Projekt (klassisch) stattdessen das project Ereignis.project_column Weitere Informationen zu Projekte (klassisch) findest du unter Informationen zu projects (classic). Informationen zu den Projektkarten-APIs finden Sie unter „Objects“ in der GraphQL-API-Dokumentation oder unter „REST-API-Endpunkte für Project (classic)-Karten.“

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

on:
  project_card:
    types: [created, deleted]

project_column

Führt deinen Workflow aus, wenn eine Spalte auf einem Projekt (klassisch) erstellt oder geändert wird. Verwende für Aktivitäten im Zusammenhang mit Projekte (klassisch) oder Karte in einem Projekt (klassisch) stattdessen das project Ereignis.project_card Weitere Informationen zu Projekte (klassisch) findest du unter Informationen zu projects (classic). Informationen zu den Projektspalten-APIs finden Sie unter „Objects“ in der GraphQL-API-Dokumentation oder unter „REST-API zum Verwalten von Projects (classic).“

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

on:
  project_column:
    types: [created, deleted]

public

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

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

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'

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 Server die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

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

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

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 Server die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

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

pull_request_review_comment

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 Server die Ereignisse pull_request, issue_comment, pull_request_review_comment, pull_request_review und pull_request_target an das Basisrepository. Im geforkten Repository treten keine Pull Request-Ereignisse ein.

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

pull_request_target

Führt deinen Workflow aus, wenn Aktivitäten für einen Pull Request im Repository des Workflows stattfinden. Wenn beispielsweise keine Aktivitätstypen angegeben werden, wird der Workflow ausgeführt, wenn ein Pull Request geöffnet oder erneut geöffnet wird oder wenn der Headbranch des Pull Requests aktualisiert wird.

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.

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

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'

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

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

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

on:
  push

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

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'

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

registry_package

jobs:
    job_name:
        if: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}

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

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

Du kannst die GitHub Enterprise Server-API verwenden, um ein Webhook-Ereignis namens repository_dispatch auszulösen, wenn du einen Workflow für Aktivitäten auslösen möchtest, die außerhalb von GitHub Enterprise Server stattfinden. Weitere Informationen findest du unter 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]

Alle Daten, die du über den Parameter client_payload sendest, stehen im github.event-Kontext in deinem Workflow zur Verfügung. Wenn du beispielsweise diesen Anforderungstext sendest, wenn du ein Repository-Versandereignis erstellst:

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

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

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

schedule

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:

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

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

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

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

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 Server-API, GitHub CLI oder GitHub Enterprise Server-Browserschnittstelle auslösen. Weitere Informationen findest du unter Manuelles Ausführen eines Workflows.

on: workflow_dispatch

Bereitstellen von Eingaben

Du kannst benutzerdefinierte Eingabeeigenschaften, Standardeingabewerte und erforderliche Eingaben für das Ereignis direkt im Workflow konfigurieren. Wenn du das Ereignis auslöst, kannst du ref und alle inputs angeben. Wenn der Workflow ausgeführt wird, kannst du auf die Eingabewerte im inputs-Kontext zugreifen. Weitere Informationen findest du unter Kontexte.

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

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

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ 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

Dieses Ereignis tritt auf, wenn eine Workflowausführung angefordert oder abgeschlossen wird. Es ermöglicht dir, einen Workflow basierend auf der Ausführung oder Fertigstellung eines anderen Workflows auszuführen. Der vom Ereignis workflow_run gestartete Workflow kann auf Geheimnisse und Schreibtoken zugreifen, auch wenn der vorherige Workflow nicht dazu in der Lage war. Dies ist in Fällen nützlich, in denen der vorherige Workflow absichtlich nicht privilegiert ist, du aber eine privilegierte Aktion in einem späteren Workflow ausführen musst.

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

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

Wenn du mehrere workflows für das workflow_run-Ereignis angibst, muss nur einer der Workflows ausgeführt werden. Ein Workflow mit dem folgenden Trigger wird beispielsweise ausgeführt, wenn der Workflow „Staging“ oder der Workflow „Lab“ abgeschlossen ist.

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

Ausführen eines Workflows basierend auf dem Abschluss eines anderen Workflows

Eine Workflowausführung wird unabhängig vom Abschluss des vorherigen Workflows ausgelöst. Wenn du einen Auftrag oder Schritt basierend auf dem Ergebnis des auslösenden Workflows ausführen möchtest, kannst du eine Bedingung mit der Eigenschaft github.event.workflow_run.conclusion verwenden. Dieser Workflow wird beispielsweise ausgeführt, wenn ein Workflow mit dem Namen „Build“ abgeschlossen ist, aber der Auftrag on-success wird nur ausgeführt, wenn der Workflow „Build“ erfolgreich war, und der Auftrag on-failure wird nur ausgeführt, wenn der Workflow „Build“ fehlgeschlagen ist:

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

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

Einschränken der Ausführung deines Workflows basierend auf Branches

Mit dem Filter branches oder branches-ignore kannst du angeben, in welchen Branches der auslösende Workflow ausgeführt werden muss, um deinen Workflow auszulösen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions. Beispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens Build in einem Branch namens canary ausgeführt wird.

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

Verwenden von Daten aus dem auslösenden Workflow

Du kannst auf die workflow_run-Ereignisnutzlast zugreifen, die dem Workflow entspricht, der deinen Workflow ausgelöst hat. Wenn dein auslösender Workflow beispielsweise Artefakte generiert, kann ein mit dem Ereignis workflow_run ausgelöster Workflow auf diese Artefakte zugreifen.

Der folgende Workflow lädt Daten als Artefakte hoch. (In diesem vereinfachten Beispiel sind die Daten die Pull-Request-Nummer.)

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v3
        with:
          name: pr_number
          path: pr/

Wenn eine Ausführung des obigen Workflows abgeschlossen ist, löst sie eine Ausführung des folgenden Workflows aus. Der folgende Workflow verwendet den Kontext github.event.workflow_run und die GitHub Enterprise Server-REST-API, um das Artefakt herunterzuladen, das vom obigen Workflow hochgeladen wurde, entzippt das heruntergeladene Artefakt und kommentiert den Pull Request, dessen Nummer als Artefakt hochgeladen wurde.

name: Use the data

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

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

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

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