# Auslösen eines Workflows So lösen Sie GitHub Actions-Workflows automatisch aus ## Voraussetzungen Weitere Informationen zu Workflows und das Auslösen von Workflows findest du unter [Workflows](/de/actions/concepts/workflows-and-actions/workflows). ## Auslösen eines Workflows aus einem Workflow Wenn Sie das `GITHUB_TOKEN` des Repositorys zum Ausführen von Aufgaben verwenden, lösen Ereignisse, die durch das `GITHUB_TOKEN` ausgelöst werden, mit den folgenden Ausnahmen keine neue Workflowausführung aus: * `workflow_dispatch` und `repository_dispatch` Ereignisse erstellen immer Workflow-Ausführungen. * `pull_request`-Ereignisse mit den Aktivitätstypen `opened`, `synchronize` oder `reopened`: Wenn ein Workflow, der `GITHUB_TOKEN` verwendet, einen Pull Request erstellt oder aktualisiert, führt das daraus resultierende `pull_request`-Ereignis zu Workflow-Ausführungen im Status **Genehmigung erforderlich**. Der Pull Request zeigt ein Banner im Merge-Feld an, und ein Benutzer mit Schreibzugriff auf das Repository kann die Durchläufe durch Auswahl von **Workflows zur Ausführung genehmigen** starten. Andere `pull_request` Aktivitätstypen (z. B. `labeled`, `edited` oder `closed`) lösen keine Workflow-Ausführungen aus. Dadurch wird verhindert, dass rekursive Workflows ausgeführt werden, während CI-Workflows weiterhin auf Pullanforderungen ausgeführt werden können, die von der Automatisierung erstellt wurden. Weitere Informationen zum Genehmigen von Workflows finden Sie unter [Genehmigen von Workflowausführungen über Forks](/de/actions/how-tos/manage-workflow-runs/approve-runs-from-forks). Bei allen anderen Ereignissen verhindert dieses Verhalten, dass Sie versehentlich rekursive Workflowausführungen erstellen. 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 finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/actions/tutorials/authenticate-with-github_token). Wenn Sie einen Workflow innerhalb einer Workflow-Ausführung auslösen möchten, können Sie ein GitHub App Installationszugriffstoken oder ein personal access token anstelle von `GITHUB_TOKEN` verwenden, um Ereignisse auszulösen, die ein Token erfordern. Wenn Sie eine dieser Alternativen verwenden, können `pull_request` Workflows auch automatisch (ohne die oben beschriebene Genehmigungsaufforderung) ausgeführt werden, wenn die Pullanforderung durch Automatisierung erstellt oder aktualisiert wird. Wenn Sie ein GitHub App verwenden, müssen Sie ein GitHub App erstellen und die App-ID sowie den privaten Schlüssel als Geheimwerte speichern. Weitere Informationen finden Sie unter [Erstellen authentifizierter API-Anforderungen mit einer GitHub App in einem GitHub Actions-Workflow](/de/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). Wenn Sie ein personal access token verwenden, müssen Sie ein personal access token erstellen und es als Geheimnis speichern. Weitere Informationen zum Erstellen eines personal access token finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Weitere Informationen zum Speichern von Geheimnissen findest du unter [Verwenden von Geheimnissen in GitHub-Aktionen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). Um Ihre GitHub Actions Nutzungskosten zu minimieren, stellen Sie sicher, dass Sie keine rekursiven oder unbeabsichtigten Workflowausführungen erstellen. Der folgende Workflow verwendet z. B. ein personal access token, das als Secret mit dem Namen `MY_TOKEN` gespeichert ist, um einem Issue mithilfe von GitHub CLI eine Bezeichnung hinzuzufügen. Sobald ein Label hinzugefügt wird und der Schritt abgeschlossen ist, werden alle zugehörigen Workflows ausgeführt. ```yaml 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. ```yaml 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](/de/actions/reference/workflows-and-actions/events-that-trigger-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: ```yaml 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: ```yaml 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](#using-event-activity-types) und [Verwenden von Filtern](#using-filters). 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 ```yaml 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..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. ```yaml on: label: types: - created ``` Wenn du mehrere Aktivitätstypen angibst, muss nur einer dieser Ereignis-Aktivitätstypen auftreten, um deinen Workflow auszulösen. Treten gleichzeitig mehrere auslösende Ereignisaktivitätstypen für deinen Workflow auf, werden mehrere Workflowausführungen ausgelöst. Beispielsweise wird der folgende Workflow ausgelöst, wenn ein Issue geöffnet oder mit einem Label versehen wird. Wenn ein Issue mit zwei Bezeichnungen geöffnet wird, werden drei Workflow-Ausführungen gestartet: eine für das Ereignis zum Öffnen des Issues und zwei für die beiden Ereignisse zum Hinzufügen von Bezeichnungen zum Issue. ```yaml on: issues: types: - opened - labeled ``` Weitere Informationen zu den einzelnen Ereignissen und ihren Aktivitätstypen findest du unter [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-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. ```yaml 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`](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) definierst, wird der Workflow nur ausgeführt, wenn beide Filter zutreffen. Die Schlüsselwörter `branches` und `branches-ignore` akzeptieren Globmuster, die Zeichen wie `*`, `**`, `+`, `?`, `!` und andere verwenden, um mit mehr als einem Branchnamen übereinzustimmen. Wenn ein Name eines dieser Zeichen enthält und du eine wörtliche Übereinstimmung möchtest, musst du jedes dieser Sonderzeichen mit `\` maskieren. Weitere Informationen zu Glob-Mustern findest du in [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### Beispiel: Einschließen von Branches Die in `branches` definierten Muster werden mit dem Namen des Git-Ref abgeglichen. Zum Beispiel würde der folgende Workflow immer dann ausgeführt, wenn ein `pull_request`-Ereignis für einen Pull Request mit folgendem Ziel ausgelöst wird: * Ein Branch mit dem Namen `main` (`refs/heads/main`) * Ein Branch mit dem Namen `mona/octocat` (`refs/heads/mona/octocat`) * Ein Branch, dessen Name mit `releases/` beginnt, wie `releases/10` (`refs/heads/releases/10`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' ``` Wenn ein Workflow aufgrund einer Branchfilterung, [Pfadfilterung](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) oder [Commitnachricht](/de/actions/how-tos/manage-workflow-runs/skip-workflow-runs) ü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`) ```yaml 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. ```yaml 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-ignore`definierst, 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`](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-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 \_\_`\`. Weitere Informationen zu Globmustern findest du unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### 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`) ```yaml 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`) ```yaml 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. ```yaml 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. Pfadfilter werden bei Pushes von Tags 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. > \[!NOTE] > Die Reihenfolge, in der `paths`-Muster definiert werden, ist entscheidend: > > * Ein passendes negatives Muster, dem nach einer positiven Übereinstimmung `!` vorangestellt ist, schließt den Pfad aus. > * Ein passendes positives Muster nach einem negativen Abgleich schließt den Pfad wieder ein. 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](/de/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### Beispiel: Einbeziehen 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. ```yaml on: push: paths: - '**.js' ``` Wenn ein Workflow aufgrund von Pfadfilterung, [Branchfilterung](/de/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) oder einer [Commitnachricht](/de/actions/how-tos/manage-workflow-runs/skip-workflow-runs) ü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. ```yaml 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. ```yaml 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 generiert die Liste der geänderten Dateien mithilfe von Zwei-Punkt-Diffs für Pushes und Drei-Punkt-Diffs für Pull Requests: * **Pull Requests:** Drei-Punkte-Diffs sind ein Vergleich zwischen der neuesten Version des Topic-Branchs und dem Commit, bei dem der Topic-Branch zuletzt mit dem Basisbranch synchronisiert wurde. * **Pushes in vorhandene Branches:** Ein Zwei-Punkte-Diff vergleicht die Head- und Basis-SHAs direkt miteinander. * **Pushes in neue Branches:** Ein Zwei-Punkte-Diff gegen das übergeordnete Element des Vorgängers des tiefsten gepushten Commits. In einigen Situationen wendet GitHub Actions Beschränkungen an, die ändern, wie gefilterte Workflows ausgeführt werden: * Wenn ein Push mehr als 1.000 Commits enthält, wird der Workflow **immer** ausgeführt. * Wenn beim Generieren des Diffs ein Timeout auftritt, wird der Workflow **immer** ausgeführt. * Wenn das generierte Diff mehr als 3.000 Dateien enthält und die Dateien, auf die der Workflow-Filter zutrifft, nicht zu den ersten 3.000 vom Filter zurückgegebenen Dateien gehören, wird der Workflow **nicht** ausgeführt. Wenn Sie diese Verhaltensweisen beobachten, müssen Sie möglicherweise Ihre Filter spezifischer machen oder ändern, wie Sie mit Push- und Pullanforderungen arbeiten, um einfachere Diffs zu generieren. Weitere Informationen finden Sie unter [Branches](/de/pull-requests/reference/branches). ### 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 Zeichen wie `*`, `**`, `+`, `?`, `!` und andere verwenden, um mit mehr als einem Branch-Namen übereinzustimmen. 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 Glob-Mustern findest du in [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). Beispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens `Build` in einem Branch namens `releases/` ausgeführt wird. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' ``` Ein Workflow mit dem folgenden Trigger wird nur ausgeführt, wenn der Workflow namens `Build` für einen Branch ausgeführt wird, der nicht `canary` heißt: ```yaml 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. ```yaml 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](/de/actions/reference/workflows-and-actions/contexts#inputs-context). > \[!NOTE] > > * Der Workflow empfängt auch die Eingaben im `github.event.inputs`-Kontext. Die Informationen im Kontext `inputs` und `github.event.inputs` sind identisch, außer dass der Kontext `inputs` boolesche Werte als solche beibehält, anstatt sie in Zeichenfolgen zu konvertieren. Der Typ `choice` wird in eine Zeichenfolge aufgelöst und ist eine einzelne auswählbare Option. > * Die maximale Anzahl von `inputs` Eigenschaften auf oberster Ebene ist 25 . > * Die maximale Länge der Nutzdaten für `inputs` beträgt 65.535 Zeichen. ```yaml 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](/de/actions/how-tos/reuse-automations/reuse-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 Webhook-Ereignis findest du allgemeine Eigenschaften und Beispiel-Payloads. Weitere Informationen finden Sie unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads). 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: ```yaml 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 GitHub CLI, um den Pull Request (`github.event.pull_request.number`) zu kennzeichnen und zu kommentieren. ```yaml 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](/de/actions/reference/workflows-and-actions/contexts). Weitere Informationen findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads) über Payloads für Ereignisse. ## Erweiterte Steuerung der Workflow-Ausfü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. ```yaml 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`. ```yaml 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](#using-event-information). Weitere Informationen zum Verwenden von Bedingungen findest du unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/reference/workflows-and-actions/expressions). ### 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](/de/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Verweisen Sie dann in einem Job Ihres 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`). ```yaml 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' ``` > \[!NOTE] > Umgebungen, Umgebungsgeheimnisse und Bereitstellungsschutzregeln sind in öffentlichen Repositories für alle aktuellen GitHub Pläne verfügbar. Sie sind für ältere Pläne, wie Bronze, Silber oder Gold, nicht erhältlich. Für den Zugriff auf Umgebungen, geheime Umgebungsschlüssel und Bereitstellungszweige in privaten oder internen Repositorys müssen Sie verwenden GitHub Pro, GitHub Teamoder GitHub Enterprise. > Wenn Sie sich in einem GitHub Free, GitHub Prooder GitHub Team einem Plan befinden, sind andere Bereitstellungsschutzregeln, wie z. B. ein Wartezeitgeber oder erforderliche Prüfer, nur für öffentliche Repositorys verfügbar. ## Verfügbare Ereignisse Eine vollständige Liste der verfügbaren Ereignisse findest du unter [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-workflows).