Auslösen eines Workflows

Voraussetzungen

Weitere Informationen zu Workflows und das Auslösen von Workflows findest du unter Workflows.

Auslösen eines Workflows aus einem Workflow

Wenn du Tasks mithilfe des GITHUB_TOKEN-Geheimnisses des Repositorys ausführst, wird durch keines der durch das GITHUB_TOKEN-Geheimnis ausgelösten Ereignisse, außer workflow_dispatch und repository_dispatch, eine neue Workflowausführung erstellt. Dadurch wird verhindert, dass du versehentlich rekursive Workflow-Ausführung erstellst. Wenn beispielsweise eine Workflowausführung Code über das GITHUB_TOKEN des Repositorys pusht, wird ein neuer Workflow auch dann nicht ausgeführt, wenn das Repository einen Workflow enthält, der für die Ausführung beim Auftreten von push-Ereignissen konfiguriert wurde. Weitere Informationen findest du unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Wenn du einen Workflow aus einer Workflowausführung heraus auslösen möchtest, kannst du anstelle von GITHUB_TOKEN ein GitHub App-Installationszugriffstoken oder ein personal access token verwenden, um Ereignisse auszulösen, für die ein Token benötigt wird.

Wenn du eine GitHub App verwendest, musst du eine GitHub App erstellen und die App-ID und den privaten Schlüssel als Geheimnisse speichern. Weitere Informationen finden Sie unter Authentifizierte API-Anforderungen mit einer GitHub-App in einem GitHub Actions-Workflow. Wenn du eine personal access token verwendest, musst du ein personal access token erstellen und als Geheimnis speichern. Weitere Informationen zum Erstellen eines personal access token findest du unter Verwalten deiner persönlichen Zugriffstoken. Weitere Informationen zum Speichern von Geheimnissen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.

Um dein Nutzungskosten für GitHub Actions zu minimieren, pass auf, dass du keine rekursiven oder unbeabsichtigten Workflow-Läufe erzeugst.

Der folgende Workflow verwendet beispielsweise ein personal access token (das als Geheimnis mit dem Namen MY_TOKEN gespeichert ist), um einem Issue über die GitHub CLI eine Bezeichnung hinzuzufügen. Alle beim Hinzufügen einer Bezeichnung ausgeführten Workflows werden nach diesem Schritt ausgeführt.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

Umgekehrt verwendet der folgende Workflow GITHUB_TOKEN, um einem Issue eine Bezeichnung hinzuzufügen. Es werden keine Workflows ausgelöst, die beim Hinzufügen einer Bezeichnung ausgeführt werden.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

Verwenden von Ereignissen zum Auslösen von Workflows

Verwende die den on-Schlüssel, um festzulegen, welche Ereignisse deinen Workflow auslösen. Weitere Informationen zu Ereignissen, die du verwenden kannst, findest du unter Ereignisse zum Auslösen von Workflows.

Verwenden eines einzelnen Ereignisses

Beispielsweise wird ein Workflow mit dem folgenden on-Wert ausgeführt, wenn in einem beliebigen Branch im Repository des Workflows ein Push erfolgt:

on: push

Verwenden mehrerer Ereignisse

Du kannst ein einzelnes Ereignis oder mehrere Ereignisse angeben. Beispielsweise wird ein Workflow mit dem folgenden on-Wert ausgeführt, wenn in einem beliebigen Branch im Repository des Workflows ein Push erfolgt oder wenn jemand ein Repository forkt:

on: [push, fork]

Wenn du mehrere Ereignisse angibst, muss nur eines dieser Ereignisse auftreten, um deinen Workflow auszulösen. Treten gleichzeitig mehrere auslösende Ereignisaktivitätstypen für deinen Workflow auf, werden mehrere Workflow-Ausführungen ausgelöst.

Verwenden von Aktivitätstypen und Filtern mit mehreren Ereignissen

Du kannst mithilfe von Aktivitätstypen und Filtern steuern, wann dein Workflow ausgeführt wird. Weitere Informationen findest du unter Verwenden von Ereignisaktivitätstypen und Verwenden von Filtern. Wenn du Aktivitätstypen oder Filter für ein Ereignis und deine Workflowauslöser für mehrere Ereignisse angibst, musst du jedes Ereignis separat konfigurieren. Du musst einen Doppelpunkt (:) an alle Ereignisse anhängen, einschließlich Ereignisse ohne Konfiguration.

Beispielsweise wird ein Workflow mit dem folgenden on-Wert ausgeführt, wenn:

• Eine Bezeichnung erstellt wird
• Ein Push an die main-Verzweigung im Repository vorgenommen wird
• Ein Push an eine GitHub Pages-aktivierte Verzweigung vorgenommen wird

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

Verwenden von Ereignisaktivitätstypen

Einige Ereignisse verfügen über Aktivitätstypen, die dir mehr Kontrolle darüber geben, wann dein Workflow ausgeführt werden soll. Verwende on.<event_name>.types, um die Art der Ereignisaktivität zu definieren, durch die eine Workflowausführung ausgelöst werden soll.

Das Ereignis issue_comment verfügt beispielsweise über die Aktivitätstypen created, edited und deleted. Wenn dein Workflow durch ein Ereignis vom Typ label ausgelöst wird, wird es ausgeführt, wenn eine Bezeichnung erstellt, bearbeitet oder gelöscht wird. Wenn du den Aktivitätstyp created für das Ereignis label angibst, wird der Workflow ausgeführt, wenn eine Bezeichnung erstellt wird, aber nicht, wenn eine Bezeichnung bearbeitet oder gelöscht wird.

on:
  label:
    types:
      - created

Bei Angabe mehrerer Aktivitätstypen wird dein Workflow ausgelöst, wenn einer dieser Ereignisaktivitätstypen auftritt. Treten gleichzeitig mehrere auslösende Ereignisaktivitätstypen für deinen Workflow auf, werden mehrere Workflowausführungen ausgelöst. Der folgende Workflow wird beispielsweise ausgelöst, wenn ein Issue erstellt oder beschriftet wird. Wenn ein Issue mit zwei Bezeichnungen erstellt wird, werden drei Workflowausführungen gestartet: eine für das Issue-Erstellungsereignis und zwei für die beiden Issue-Beschriftungsereignisse.

on:
  issues:
    types:
      - opened
      - labeled

Weitere Informationen zu den einzelnen Ereignissen und ihren Aktivitätstypen findest du unter Ereignisse zum Auslösen von Workflows.

Verwenden von Filtern

Einige Ereignisse verfügen über Filter, die Ihnen mehr Kontrolle darüber geben, wann Ihr Workflow ausgeführt werden soll.

Das push-Ereignis verfügt beispielsweise über einen branches-Filter. Dieser führt dazu, dass der Workflow nicht bei jedem beliebigen Push, sondern nur bei einem Push an einen Branch ausgeführt wird, der mit dem branches-Filter übereinstimmt.

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

Verwenden von Filtern, um spezifische Branches als Ziel für Pull Request-Ereignisse festzulegen

Wenn Du die Ereignisse pull_request und pull_request_target verwendest, kannst Du einen Workflow konfigurieren, der nur für Pull Requests ausgeführt werden kann, die auf bestimmte Branches abzielen.

Verwende den Filter branches, wenn Du Branchnamenmuster entweder einschließen oder ein- und ausschließen möchtest. Verwende den Filter branches-ignore, wenn du Branchnamenmuster nur ausschließen möchtest. Du kannst die Filter branches und branches-ignore nicht für dasselbe Ereignis in einem Workflow nutzen.

Wenn du sowohl branches/branches-ignore als auch paths/paths-ignore definierst, wird der Workflow nur ausgeführt, wenn beide Filter zutreffen.

Die Schlüsselwörter branches und branches-ignore akzeptieren Globmuster, die die Platzhalterzeichen *, **, +, ?, ! verwenden, um zu mehr als einem Branchnamen zu passen. Wenn ein Name eines dieser Zeichen enthält und Du eine literale Übereinstimmung wünscht, musst Du jedes dieser Sonderzeichen mit \ als Escapezeichen verwenden. Weitere Informationen zu Globmustern findest du unter Workflowsyntax für GitHub Actions.

Beispiel: Einschließen von Branches

Die in branches definierten Muster werden mit dem Namen des Git-Ref ausgewertet. Der folgende Workflow würde zum Beispiel immer dann ablaufen, wenn ein pull_request-Ereignis für einen Pull Request vorliegt:

• Ein Branch namens main (refs/heads/main)
• Ein Branch namens mona/octocat (refs/heads/mona/octocat)
• Ein Branch, dessen Name mit releases/ beginnt, wie releases/10 (refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

Sie sollten keine Pfad- oder Branchfilterung verwenden, um Workflowausführungen zu überspringen, wenn der Workflow vor der Zusammenführung durchlaufen werden muss. Weitere Informationen findest du unter Überspringen von Workflowausführungen und Verfügbare Regeln für Regelsätze.

Wenn ein Workflow aufgrund einer Branchfilterung, Pfadfilterung oder Commitnachricht übersprungen wird, verbleiben diesem Workflow zugeordnete Überprüfungen im Status „Ausstehend“. Ein Pull Request, bei dem diese Prüfungen erfolgreich sein müssen, wird vom Mergen ausgeschlossen.

Beispiel: Ausschließen von Branches

Wenn ein Muster dem Muster branches-ignore entspricht, wird der Workflow nicht ausgeführt. Die in branches-ignore definierten Muster werden mit dem Namen des Git-Ref ausgewertet. Der folgende Arbeitsablauf würde zum Beispiel immer dann ablaufen, wenn ein pull_request-Ereignis eintritt, es sei denn, der Pull Request ist zielgerichtet:

• Ein Branch namens mona/octocat (refs/heads/mona/octocat)
• Ein Branch, dessen Name mit releases/**-alpha übereinstimmt, wie releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

Beispiel: Einschließen und Ausschließen von Branches

Du kannst dasselbe Ereignis nicht mit branches und branches-ignore in einem einzigen Workflow filtern. Wenn Du Branchmuster für ein einzelnes Ereignis sowohl einschließen als auch ausschließen möchten, verwendest Du den Filter branches zusammen mit dem Zeichen !, um die auszuschließenden Branches anzugeben.

Wenn Du einen Branch mit dem Zeichen ! definierst, musst Du auch mindestens einen Branch ohne das Zeichen ! definieren. Wenn Du nur Branches ausschließen möchten, verwendest Du stattdessen branches-ignore.

Die Reihenfolge, in der Du die Muster definierst, ist entscheidend.

• Ein passendes negatives Muster (mit dem Präfix !) nach einer positiven Übereinstimmung schließt den Verweis auf Git aus.
• Ein übereinstimmendes positives Muster nach einem negativen Abgleich schließt die Git-Ref wieder ein.

Der folgende Workflow wird bei pull_request-Ereignissen für Pull Requests ausgeführt, die auf releases/10 oder releases/beta/mona abzielen, aber nicht für Pull-Requests, die auf releases/10-alpha oder releases/beta/3-alpha abzielen, weil das negative Muster !releases/**-alpha auf das positive Muster folgt.

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Verwenden von Filtern, um spezifische Branches als Ziel oder Tags für Pushereignisse festzulegen

Wenn du das push-Ereignis verwendest, kannst du einen Workflow so konfigurieren, dass er auf bestimmten Branches oder Tags ausgeführt wird.

Verwende den Filter branches, wenn du Branchnamenmuster entweder einschließen oder ein- und ausschließen möchtest. Verwende den Filter branches-ignore, wenn du Branchnamenmuster nur ausschließen möchtest. Du kannst die Filter branches und branches-ignore nicht für dasselbe Ereignis in einem Workflow nutzen.

Verwende den Filter tags, wenn du Tagnamenmuster entweder einschließen oder ein- und ausschließen möchtest. Verwende den Filter tags-ignore, wenn du Tagnamenmuster nur ausschließen möchtest. Du kannst die Filter tags und tags-ignore nicht für dasselbe Ereignis in einem Workflow nutzen.

Wenn du nur tags/tags-ignore oder nur branches/branches-ignoredefinierst, wird der Workflow nicht für Ereignisse ausgeführt, die die nicht definierte Git-Referenz betreffen. Wenn du weder tags/tags-ignore noch branches/branches-ignore definierst, wird der Workflow für Ereignisse ausgeführt, die alle Branches oder Tags betreffen. Wenn du sowohl branches/branches-ignore als auch paths/paths-ignore definierst, wird der Workflow nur ausgeführt, wenn beide Filter zutreffen.

Die Schlüsselwörter branches, branches-ignore, tags und tags-ignore akzeptieren Globmuster, die die Zeichen *, **, +, ?, ! etc. verwenden, um mehr als einem Branch- oder Tagnamen zu entsprechen. Wenn ein Name eines dieser Zeichen enthält und du eine genaue Übereinstimmung möchtest, musst du jedes dieser Sonderzeichen mit \ versehen. Weitere Informationen zu Globmustern findest du unter Workflowsyntax für GitHub Actions.

Beispiel: Einschließen von Branches und Tags

Die in branches und tags definierten Muster werden anhand des Namens des Git-Verweises ausgewertet. Der folgende Workflow wird beispielsweise jedes Mal ausgeführt, wenn ein push-Ereignis an folgende Instanzen ausgeführt wird:

• Ein Branch namens main (refs/heads/main)
• Ein Branch namens mona/octocat (refs/heads/mona/octocat)
• Ein Branch, dessen Name mit releases/ beginnt, wie releases/10 (refs/heads/releases/10)
• Ein Tag namens v2 (refs/tags/v2)
• Ein Tag, dessen Name mit v1. beginnt, wie v1.9.1 (refs/tags/v1.9.1)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

Beispiel: Ausschließen von Branches und Tags

Wenn ein Muster dem Muster branches-ignore oder tags-ignore entspricht, wird der Workflow nicht ausgeführt. Die in branches und tags definierten Muster werden anhand des Namens des Git-Verweises ausgewertet. Der folgende Workflow wird beispielsweise immer dann ausgeführt, wenn ein push-Ereignis auftritt, es sei denn, das push-Ereignis wird an folgende Instanzen ausgeführt:

• Ein Branch namens mona/octocat (refs/heads/mona/octocat)
• Ein Branch, dessen Name mit releases/**-alpha übereinstimmt, wie releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)
• Ein Tag namens v2 (refs/tags/v2)
• Ein Tag, dessen Name mit v1. beginnt, wie v1.9 (refs/tags/v1.9)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v2
      - v1.*

Beispiel: Einschließen und Ausschließen von Branches und Tags

Du kannst branches und branches-ignore nicht verwenden, um dasselbe Ereignis in einem einzigen Workflow zu filtern. Ebenso kannst du tags und tags-ignore nicht verwenden, um dasselbe Ereignis in einem einzigen Workflow zu filtern. Wenn du Branch- oder Tagmuster für ein einzelnes Ereignis sowohl einschließen als auch ausschließen möchtest, verwende den Filter branches oder tags zusammen mit dem Zeichen !, um die auszuschließenden Branches und Tags anzugeben.

Wenn du einen Branch mit dem Zeichen ! definierst, musst du auch mindestens einen Branch ohne das Zeichen ! definieren. Wenn du nur Branches ausschließen möchtest, verwende stattdessen branches-ignore. Wenn du ebenfalls einen Tag mit dem Zeichen ! definierst, musst du auch mindestens einen Tag ohne das Zeichen ! definieren. Wenn du nur Tags ausschließen möchtest, verwende stattdessen tags-ignore.

Die Reihenfolge, in der Du die Muster definierst, ist entscheidend.

• Ein passendes negatives Muster (mit dem Präfix !) nach einer positiven Übereinstimmung schließt den Verweis auf Git aus.
• Ein übereinstimmendes positives Muster nach einem negativen Abgleich schließt die Git-Ref wieder ein.

Der folgenden Workflow führt Pushes an releases/10 oder releases/beta/mona aus, aber nicht an releases/10-alpha oder releases/beta/3-alpha, da das negative Muster !releases/**-alpha dem positiven Muster folgt.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Verwenden von Filtern, um spezifische Pfade als Ziel für Pull Request- oder Pushereignisse festzulegen

Wenn du die Ereignisse push und pull_request verwendest, kannst du einen Workflow konfigurieren, der basierend auf den geänderten Dateipfaden ausgeführt wird. Bei Push-Vorgängen zu Tags werden Pfadfilter nicht ausgewertet.

Verwende den Filter paths, wenn du Dateipfadmuster entweder einschließen oder einschließen und ausschließen möchtest. Verwende den Filter paths-ignore, wenn du Dateipfadmuster nur ausschließen möchtest. Du kannst die Filter paths und paths-ignore nicht für dasselbe Ereignis in einem Workflow nutzen. Wenn Pfadmuster für ein einzelnes Ereignis sowohl eingeschlossen als auch ausgeschlossen werden sollen, benutzen Sie den Filter paths mit dem vorangestellten Zeichen !, um die auszuschließenden Pfade anzugeben.

Wenn du sowohl branches/branches-ignore als auch paths/paths-ignore definierst, wird der Workflow nur ausgeführt, wenn beide Filter zutreffen.

Die Schlüsselwörter paths und paths-ignore akzeptieren Globmuster, die die Platzhalterzeichen * und ** verwenden, um zu mehr als einem Pfadnamen zu passen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Beispiel: Einschließen von Pfaden

Wenn mindestens ein Pfad zu einem Muster im Filter paths passt, wird der Workflow ausgeführt. Der folgende Workflow wird beispielsweise jedes Mal ausgeführt, wenn du eine JavaScript-Datei (.js) pushst.

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

Sie sollten keine Pfad- oder Branchfilterung verwenden, um Workflowausführungen zu überspringen, wenn der Workflow vor der Zusammenführung durchlaufen werden muss. Weitere Informationen findest du unter Überspringen von Workflowausführungen und Verfügbare Regeln für Regelsätze.

Wenn ein Workflow aufgrund von Pfadfilterung, Branchfilterung oder einer Commitnachricht übersprungen wird, verbleiben diesem Workflow zugeordnete Überprüfungen im Status „Ausstehend“. Ein Pull Request, bei dem diese Prüfungen erfolgreich sein müssen, wird vom Mergen ausgeschlossen.

Beispiel: Ausschließen von Pfaden

Wenn alle Pfadnamen mit Mustern in paths-ignore übereinstimmen, wird der Workflow nicht ausgeführt. Wenn manche Pfadnamen nicht mit Mustern in paths-ignore übereinstimmen, wird der Workflow ausgeführt, obwohl einige Pfadnamen den Mustern entsprechen.

Ein Workflow mit dem folgenden Pfadfilter wird nur bei push-Ereignissen ausgeführt, bei denen sich mindestens eine Datei außerhalb des Verzeichnisses docs im Stamm des Repositorys befindet.

on:
  push:
    paths-ignore:
      - 'docs/**'

Beispiel: Einschließen und Ausschließen von Pfaden

Du kannst dasselbe Ereignis nicht mit paths und paths-ignore in einem einzigen Workflow filtern. Wenn Pfadmuster für ein einzelnes Ereignis sowohl eingeschlossen als auch ausgeschlossen werden sollen, benutzen Sie den Filter paths mit dem vorangestellten Zeichen !, um die auszuschließenden Pfade anzugeben.

Wenn du einen Pfad mit dem Zeichen ! definierst, musst du auch mindestens einen Pfad ohne das Zeichen ! definieren. Wenn du nur Pfade ausschließen möchtest, verwende stattdessen paths-ignore.

Die Reihenfolge, in der paths-Muster definiert werden, ist entscheidend:

• Ein passendes negatives Muster mit dem Präfix ! nach einem positiven Abgleich schließt den Pfad aus.
• Ein passendes positives Muster nach einem negativen Abgleich schließt den Pfad wieder ein.

In diesem Beispiel wird jedes Mal ausgeführt, wenn das Ereignis push eine Datei im Verzeichnis sub-project oder in seinen Unterverzeichnissen enthält, es sei denn, die Datei befindet sich im Verzeichnis sub-project/docs. Beispielsweise löst in Push, der sub-project/index.js oder sub-project/src/index.js geändert hat, die Ausführung eines Workflows aus, dies geschieht jedoch nicht, wenn nur sub-project/docs/readme.md geändert wurde.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Git-Diff-Vergleiche

Um zu ermitteln, ob ein Workflow ausgeführt werden soll, wertet der Filter die geänderten Dateien anhand der Listen paths-ignore oder paths aus. Wurden keine Dateien geändert, wird der Workflow nicht ausgeführt.

GitHub erzeugt die Liste der geänderten Dateien mithilfe von „Two-Dot-Diffs“ (Vergleiche mittels 2 Punkt-Syntax „..“) für Push-Vorgänge und „Three-Dot-Diffs“ (Vergleiche mittels 3 Punkt-Syntax „...“) für Pull-Requests:

• Pull Requests: Three-Dot-Diffs ziehen den Vergleich zwischen der neuesten Version des Topic-Branch und des Commit, bei dem der Topic-Branch zuletzt mit dem Basis-Branch synchronisiert wurde.
• Push-Vorgänge an bestehende Branches: Eine Two-Dot-Diff vergleicht die Head- und Basis-SHAs direkt miteinander.
• Push-Vorgänge an neue Branches: Eine Two-Dot-Diff wird zum übergeordneten Element des Vorgängers des tiefsten Commits gepusht.

Weitere Informationen finden Sie unter Informationen zum Vergleich von Branches in Pull Requests.

Verwenden von Filtern, um spezifische Branches als Ziel für Workflowausführungsereignisse festzulegen

Wenn du das workflow_run-Ereignis verwendest, kannst du angeben, in welchen Branches der auslösende Workflow ausgeführt werden muss, um deinen Workflow auszulösen.

Die Filter branches und branches-ignore akzeptieren Globmuster, die die Platzhalterzeichen *, **, +, ?, ! und andere verwenden, um zu mehr als einem Branch-Namen zu passen. Wenn ein Name eines dieser Zeichen enthält und du eine literale Übereinstimmung wünscht, musst du für jedes dieser Sonderzeichen mit Escape mit \ verwenden. Weitere Informationen zu Globmustern 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 releases/ ausgeführt wird.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

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-ignore:
      - "canary"

Du kannst die Filter branches und branches-ignore nicht für dasselbe Ereignis in einem Workflow nutzen. Wenn du Branch-Muster für ein einzelnes Ereignis sowohl einschließen als auch ausschließen möchtest, verwende den branches-Filter zusammen mit dem !-Zeichen, um die auszuschließenden Branches anzugeben.

Die Reihenfolge, in der Du die Muster definierst, ist entscheidend.

• Ein passendes negatives Muster (Präfix !) nach einem positiven Abgleich schließt die Branch aus.
• Ein passendes positives Muster nach einem negativen Abgleich schließt die Branch wieder ein.

Beispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens Build in einem Branch namens releases/10 oder releases/beta/mona, aber nicht releases/10-alpha, releases/beta/3-alpha oder main ausgeführt wird.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Definieren von Eingaben für manuell ausgelöste Workflows

Bei Verwendung des workflow_dispatch-Ereignisses kannst du optional Eingaben angeben, die an den Workflow übergeben werden.

Dieser Trigger empfängt nur Ereignisse, wenn sich die Workflow-Datei auf dem Standardbranch befindet. Der ausgelöste Workflow empfängt die Eingaben im Kontext inputs. Weitere Informationen findest du unter Contexts.

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

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if: ${{ inputs.print_tags }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ inputs.tags }} 

Definieren von Eingaben, Ausgaben und Geheimnissen für wiederverwendbare Workflows

Du kannst Eingaben und Geheimnisse definieren, die ein wiederverwendbarer Workflow von einem aufrufenden Workflow empfangen soll. Du kannst außerdem Ausgaben festlegen, die ein wiederverwendbarer Workflow einem aufrufenden Workflow zur Verfügung stellen soll. Weitere Informationen finden Sie unter Wiederverwenden von Workflows.

Verwenden von Ereignisinformationen

Im github.event-Kontext stehen Informationen über das Ereignis zur Verfügung, das eine Workflowausführung ausgelöst hat. Die Eigenschaften im github.event-Kontext hängen vom Typ des Ereignisses ab, das den Workflow ausgelöst hat. Zum Beispiel würde ein Workflow, der durch die Bezeichnung eines Issues ausgelöst wird, Informationen über das Issue und die Bezeichnung enthalten.

Anzeigen aller Eigenschaften eines Ereignisses

In der Dokumentation zum Webhookereignis findest du allgemeine Eigenschaften und Beispielnutzdaten. Weitere Informationen finden Sie unter Webhook-Ereignisse und -Nutzlasten.

Du kannst auch den gesamten github.event-Kontext ausgeben, um zu ermitteln, welche Eigenschaften für das Ereignis verfügbar sind, das deinen Workflow ausgelöst hat:

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

Zugreifen auf und Verwenden von Ereigniseigenschaften

Du kannst den github.event-Kontext in deinem Workflow verwenden. Der folgende Workflow wird zum Beispiel ausgeführt, wenn ein Pull Request geöffnet wird, der package*.json, .github/CODEOWNERS oder .github/workflows/** ändert. Wenn der Autor des Pull Requests (github.event.pull_request.user.login) nicht octobot oder dependabot[bot] ist, verwendet der Workflow die GitHub CLI, um den Pull Request zu kennzeichnen und zu kommentieren (github.event.pull_request.number).

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

Weitere Informationen zu Kontexten findest du unter Kontextreferenz. Weitere Informationen zu Ereignisnutzdaten findest du unter Webhook-Ereignisse und -Nutzlasten.

Weiterführende Steuerung der Workflowausführung

Wenn du eine präzisere Kontrolle benötigst, als Ereignisse, Ereignisaktivitätstypen oder Ereignisfilter sie bieten, kannst du Bedingungen und Umgebungen verwenden, um zu steuern, ob einzelne Aufträge oder Schritte in deinem Workflow ausgeführt werden.

Verwenden von Bedingungen

Du kannst Bedingungen verwenden, um genauer zu steuern, ob Aufträge oder Schritte in deinem Workflow ausgeführt werden sollen.

Beispiel für die Verwendung eines Werts in der Ereignisnutzlast

Wenn du zum Beispiel möchtest, dass der Workflow ausgeführt wird, wenn einem Issue eine bestimmte Bezeichnung hinzugefügt wird, kannst du die Ereignisaktivität issues labeled auslösen und anhand einer Bedingung prüfen, welche Bezeichnung den Workflow ausgelöst hat. Der folgende Workflow wird ausgeführt, wenn einem Issue im Repository des Workflows eine beliebige Bezeichnung hinzugefügt wird, aber der Auftrag run_if_label_matches wird nur ausgeführt, wenn die Bezeichnung bug lautet.

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

Beispiel für die Verwendung eines Ereignistyps

Wenn du zum Beispiel abhängig davon, welches Ereignis den Workflow ausgelöst hat, verschiedene Aufträge oder Schritte ausführen möchtest, kannst du anhand einer Bedingung prüfen, ob ein bestimmter Ereignistyp im Ereigniskontext vorhanden ist. Der folgende Workflow wird immer dann ausgeführt, wenn ein Issue oder Pull Request geschlossen wird. Wenn der Workflow ausgeführt wurde, weil ein Issue geschlossen wurde, enthält der Kontext github.event einen Wert für issue, aber nicht für pull_request. Deshalb wird der Schritt if_issue ausgeführt, aber der Schritt if_pr nicht. Wenn der Workflow hingegen ausgeführt wurde, weil ein Pull Request geschlossen wurde, wird der Schritt if_pr ausgeführt, aber nicht der Schritt if_issue.

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

Weitere Informationen darüber, welche Informationen im Ereigniskontext verfügbar sind, findest du unter Verwenden von Ereignisinformationen. Weitere Informationen zum Verwenden von Bedingungen findest du unter Auswerten von Ausdrücken in Workflows und Aktionen.

Verwenden von Umgebungen zum manuellen Auslösen von Workflowaufträgen

Wenn du einen bestimmten Auftrag in einem Workflow manuell auslösen möchtest, kannst du eine Umgebung verwenden, die die Genehmigung eines bestimmten Teams oder Benutzers erfordert. Konfiguriere zunächst eine Umgebung mit den erforderlichen Prüfern. Weitere Informationen finden Sie unter Verwalten von Umgebungen für die Bereitstellung. Dann verweist du in einem Auftrag deines Workflows mit dem Schlüssel environment: auf den Umgebungsnamen. Jeder Auftrag mit Verweis auf die Umgebung wird erst ausgeführt, wenn mindestens ein Prüfer den Auftrag genehmigt.

Der folgende Workflow wird beispielsweise bei jedem Push an den Mainbranch ausgeführt. Der Auftrag build wird immer ausgeführt. Der Auftrag publish wird erst ausgeführt, nachdem der Auftrag build erfolgreich abgeschlossen wurde (aufgrund von needs: [build]) und nachdem alle Regeln (einschließlich der erforderlichen Prüfer) für die Umgebung namens production erfüllt wurden (aufgrund von environment: production).

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        run: |
          echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        run: |
          echo 'publishing'

Verfügbare Ereignisse

Eine vollständige Liste der verfügbaren Ereignisse findest du unter Ereignisse zum Auslösen von Workflows.