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 über die Verwendung von Workflow-Triggern 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 darüber, was die einzelnen Aktivitätstypen bedeuten, 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 über die Branch-Schutzregel-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 über die APIs zum Ausführen von Checks findest du unter Objects in der GraphQL API-Dokumentation oder 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 APIs der Check-Suite findest du unter Objects in der GraphQL API-Dokumentation oder 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 über die APIs zum Erstellen einer Git-Referenz findest du unter Mutationen in der GraphQL API-Dokumentation oder REST-API-Endpunkte für Git-Verweise.

Du kannst 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 über die APIs zum Löschen einer Git-Referenz findest du unter Mutationen in der GraphQL API-Dokumentation oder REST-API-Endpunkte für Git-Verweise.

Du kannst 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 eine Git-Referenz. Informationen über die APIs zum Erstellen einer Bereitstellung findest du unter Mutationen in der GraphQL API-Dokumentation oder REST-API-Endpunkte für Repositorys.

Du kannst 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, haben möglicherweise keine Git-Referenz. Informationen über die APIs zum Erstellen eines Bereitstellungsstatus findest du unter Mutationen in der GraphQL API-Dokumentation oder 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. Für Aktivitäten, die sich auf Kommentare zu einer Diskussion beziehen, verwende das discussion_comment-Ereignis. Weitere Informationen über Diskussionen findest du unter Informationen zu Diskussionen. Informationen über die 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. Für Aktivitäten, die sich auf eine Diskussion beziehen, im Gegensatz zu Kommentaren zu einer Diskussion, verwende das discussion-Ereignis. Weitere Informationen über Diskussionen findest du unter Informationen zu Diskussionen. Informationen über die 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 über die 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

image_version

Führt Ihren Workflow aus, wenn eine neue Version eines angegebenen Bilds zur Verwendung verfügbar wird. Dieses Ereignis wird in der Regel nach einer erfolgreichen Erstellung einer Imageversion ausgelöst, sodass Sie Aktionen wie bereitstellungs- oder Benachrichtigungen als Reaktion auf neue Imageversionen automatisieren können.

Dieses Ereignis unterstützt Glob-Patterns sowohl für Image-Namen als auch für Versionen. Das folgende Beispiel wird ausgelöst, wenn eine neue Bildversion mit einer der angegebenen Kombinationen aus Namen und Version übereinstimmt. Beispiel: ["MyNewImage", 1.0.0], , ["MyNewImage", 2.53.0], ["MyOtherImage", 1.0.0], und ["MyOtherImage", 2.0.0].

on:
  image_version:
    names:
    - "MyNewImage"
    - "MyOtherImage"
    versions:
    - 1.*
    - 2.*

issue_comment

Führt deinen Workflow aus, wenn ein Issue oder ein Pull-Request-Kommentar erstellt, bearbeitet oder gelöscht wird. Informationen zu den Problem-Kommentar-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 Problemen oder 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. Für Aktivitäten, die sich auf Kommentare in einem Problem beziehen, verwende das issue_comment-Ereignis. Weitere Informationen zu Problemen findest du unter Informationen zu Issues. Informationen über die Problem-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 über Labels findest du unter Verwalten von Bezeichnungen. Informationen über die Labels-APIs findest du unter Objects in der GraphQL API-Dokumentation oder REST-API-Endpunkte für Bezeichnungen.

Wenn du deinen Workflow ausführen möchtest, wenn ein Label zu einem Problem, Pull-Request oder einer Diskussion hinzugefügt oder entfernt wird, verwende stattdessen die labeled- oder unlabeled-Aktivitätstypen für die issues-, pull_request-, pull_request_target- oder discussion-Ereignisse.

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

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

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 über die Meilenstein-APIs findest du unter Objects in der GraphQLAPI-Dokumentation oder REST-API-Endpunkte für Meilensteine.

Wenn du deinen Workflow ausführen willst, wenn ein Problem zu einem Meilenstein hinzugefügt oder aus ihm entfernt wird, verwende stattdessen die milestoned oder demilestoned Aktivitätstypen für das issues-Ereignis.

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 über die 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

Führt deinen Workflow aus, wenn sich das Repository deines Workflows von privat in öffentlich ändert. Informationen über die 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. Für Aktivitäten, die sich auf Pull-Reviews, Pull-Review-Kommentare oder Pull-Request-Kommentare beziehen, verwende stattdessen die pull_request_review-, pull_request_review_comment- oder issue_comment-Ereignisse. Informationen über die Pull-Request-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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. Um einen Workflow auszuführen, wenn eine Pull-Request zusammengeführt wird, verwende 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 finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub 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 (verwende issue_comment)

Um deinen Workflow auszuführen, wenn ein Kommentar zu einer Pull-Request (nicht zum Diff einer Pull-Request) erstellt, bearbeitet oder gelöscht wird, verwende das issue_comment-Ereignis. Für Aktivitäten, die sich auf Pull-Reviews oder Kommentare zu Pull-Reviews beziehen, verwendest du die pull_request_review- oder pull_request_review_comment-Ereignisse.

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. Für Aktivitäten, die sich auf Pull-Request-Review-Kommentare oder Pull-Request-Kommentare beziehen, verwende stattdessen die pull_request_review_comment- oder issue_comment-Ereignisse. Informationen zu den Pull-Request-Review-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub 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. Für Aktivitäten im Zusammenhang mit Pull-Review- oder Pull-Request Kommentaren, verwende stattdessen die pull_request_review- oder issue_comment-Ereignisse. Informationen zu den Pull-Request-Kommentar-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Pull-Request-Ereignisse für geforkte Repositorys

Für Pull Requests von einem geforkten Repository an das Basisrepository sendet GitHub 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 der Pull-Request ausgeführt und nicht im Kontext des Merge-Commits, wie beim pull_request-Ereignis. 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. Um einen Workflow auszuführen, wenn eine Pull-Request zusammengeführt wird, verwende 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'

registry_package

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

Führt deinen Workflow aus, wenn die Freigabeaktivität in deinem Repository stattfindet. Informationen über die Veröffentlichungs-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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-API ein Webhook-Ereignis mit dem Namen repository_dispatch auslösen, wenn du einen Workflow für eine Aktivität auslösen willst, die außerhalb von GitHub stattfindet. 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 einen Workflow zum Ausführen aus. Du kannst das Schlüsselwort types verwenden, damit der Workflow nur ausgeführt wird, wenn ein bestimmter event_type-Wert im Webhook-Payload 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 den Payload 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.

             **Beispiel:**

 on:
   schedule:
     - cron: "15 4,5 * * *"

Verwende die POSIX-Cron-Syntax, um die Ausführung von Workflows zu bestimmten UTC-Zeiten zu planen. Geplante Workflows werden für den letzten Commit auf dem Standardbranch ausgeführt. Das kürzeste Intervall, in dem Du geplante Workflows ausführen kannst, ist einmal alle 5 Minuten.

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:

Ein einzelner Workflow kann durch mehrere schedule-Ereignisse ausgelöst werden. Greife über den Kontext github.event.schedule auf das schedule-Ereignis zu, das den Workflow ausgelöst hat. In diesem Beispiel wird der Workflow so ausgelöst, dass er jeden Montag bis Donnerstag um 5:30 UTC und am Dienstag und Donnerstag um 17:30 UTC ausgeführt wird, überspringt jedoch Schritt Not on Monday or Wednesday am Montag und Mittwoch.

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

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.

actor für geplante Workflows

Bestimmte Repositoryereignisse ändern den dem Workflow zugeordneten actor. Beispielsweise wird ein Benutzer, der den Default-Branch des Repositorys ändert, was den Branch ändert, auf dem geplante Workflows ausgeführt werden, für diese geplanten Workflows der actor.

Wenn ein Benutzer mit write-Berechtigungen für das Repository bei einem deaktivierten geplanten Workflow einen Commit erstellt, der den cron-Zeitplan für den Workflow ändert, wird der Workflow erneut aktiviert, und dieser Benutzer wird zum actor-Element, das einer beliebigen Workflowausführung zugeordnet ist.

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 mehr Details über die Statusänderung angeben möchtest, kannst du das check_run-Ereignis verwenden. Informationen über die Commit-Status-APIs findest du unter Objects in der GraphQL API-Dokumentation oder 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 über die Pull-Request-APIs findest du unter Mutationen in der GraphQL API-Dokumentation oder REST-API-Endpunkte zum Versehen mit einem Stern.

Du kannst z. B. einen Workflow ausführen, wenn ein Repository mit einem Stern markiert wird, wobei es sich um den Aktivitätstyp started für ein Überwachungsereignis handelt.

on:
  watch:
    types: [started]

workflow_call

          `workflow_call` wird verwendet, um anzuzeigen, dass ein Workflow von einem anderen Workflow aufgerufen werden kann. Wenn ein Workflow mit dem `workflow_call`-Ereignis ausgelöst wird, ist der Ereignis-Payload im aufgerufenen Workflow derselbe Ereignis-Payload wie aus dem aufrufenden Workflow. Weitere Informationen findest du unter [AUTOTITLE](/actions/using-workflows/reusing-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 einen Workflow manuell über die GitHub-API, GitHub CLI oder die GitHub-Benutzeroberfläche 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 Kontextreferenz.

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 die Werte dann 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 unter den GitHub CLI-Informationen in 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 den workflow_run-Ereignis-Payload zugreifen, der 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 github.event.workflow_run-Kontext und die GitHub-REST-API, um das Artefakt herunterzuladen, das durch den obigen Workflow hochgeladen wurde, entpackt das heruntergeladene Artefakt und kommentiert die Pull-Request, deren 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@v8
        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',
            });
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            if (!fs.existsSync(temp)){
              fs.mkdirSync(temp);
            }
            fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip "${{ runner.temp }}/artifacts/pr_number.zip" -d "${{ runner.temp }}/artifacts"

      - name: 'Comment on PR'
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            const issue_number = Number(fs.readFileSync(path.join(temp, '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!'
            });