{"meta":{"title":"Auslösen eines Workflows","intro":"So lösen Sie GitHub Actions-Workflows automatisch aus","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/how-tos","title":"Anleitungen"},{"href":"/de/actions/how-tos/write-workflows","title":"Schreiben von Workflows"},{"href":"/de/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Auswählen, wann Workflows ausgeführt werden"},{"href":"/de/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"Auslösen eines Workflows"}],"documentType":"article"},"body":"# Auslösen eines Workflows\n\nSo lösen Sie GitHub Actions-Workflows automatisch aus\n\n## Voraussetzungen\n\nWeitere Informationen zu Workflows und das Auslösen von Workflows findest du unter [Workflows](/de/actions/concepts/workflows-and-actions/workflows).\n\n## Auslösen eines Workflows aus einem Workflow\n\nWenn 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:\n\n* `workflow_dispatch` und `repository_dispatch` Ereignisse erstellen immer Workflow-Ausführungen.\n* `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).\n\nBei 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).\n\nWenn 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.\n\nWenn 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).\n\nUm Ihre GitHub Actions Nutzungskosten zu minimieren, stellen Sie sicher, dass Sie keine rekursiven oder unbeabsichtigten Workflowausführungen erstellen.\n\nDer 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.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\nUmgekehrt 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.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## Verwenden von Ereignissen zum Auslösen von Workflows\n\nVerwende 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).\n\n### Verwenden eines einzelnen Ereignisses\n\nBeispielsweise wird ein Workflow mit dem folgenden `on`-Wert ausgeführt, wenn in einem beliebigen Branch im Repository des Workflows ein Push erfolgt:\n\n```yaml\non: push\n```\n\n### Verwenden mehrerer Ereignisse\n\nDu 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:\n\n```yaml\non: [push, fork]\n```\n\nWenn 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.\n\n### Verwenden von Aktivitätstypen und Filtern mit mehreren Ereignissen\n\nDu 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.\n\nBeispielsweise wird ein Workflow mit dem folgenden `on`-Wert ausgeführt, wenn:\n\n* Eine Bezeichnung erstellt wird\n* Ein Push an die `main`-Verzweigung im Repository vorgenommen wird\n* Ein Push an eine GitHub Pages-aktivierte Verzweigung vorgenommen wird\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## Verwenden von Ereignisaktivitätstypen\n\nEinige 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.\n\nDas 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.\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\nWenn 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.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\nWeitere 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).\n\n## Verwenden von Filtern\n\nEinige Ereignisse verfügen über Filter, die Ihnen mehr Kontrolle darüber geben, wann Ihr Workflow ausgeführt werden soll.\n\nDas `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.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### Verwenden von Filtern, um spezifische Branches als Ziel für Pull Request-Ereignisse festzulegen\n\nWenn 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.\n\nVerwende 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.\n\nWenn 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.\n\nDie 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).\n\n#### Beispiel: Einschließen von Branches\n\nDie 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:\n\n* Ein Branch mit dem Namen `main` (`refs/heads/main`)\n* Ein Branch mit dem Namen `mona/octocat` (`refs/heads/mona/octocat`)\n* Ein Branch, dessen Name mit `releases/` beginnt, wie `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nWenn 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.\n\n#### Beispiel: Ausschließen von Branches\n\nWenn 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:\n\n* Ein Branch namens `mona/octocat` (`refs/heads/mona/octocat`)\n* Ein Branch, dessen Name mit `releases/**-alpha` übereinstimmt, wie `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n#### Beispiel: Einschließen und Ausschließen von Branches\n\nDu 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.\n\nWenn 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`.\n\nDie Reihenfolge, in der Du die Muster definierst, ist entscheidend.\n\n* Ein passendes negatives Muster (mit dem Präfix `!`) nach einer positiven Übereinstimmung schließt den Verweis auf Git aus.\n* Ein übereinstimmendes positives Muster nach einem negativen Abgleich schließt die Git-Ref wieder ein.\n\nDer 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Verwenden von Filtern, um spezifische Branches als Ziel oder Tags für Pushereignisse festzulegen\n\nWenn du das `push`-Ereignis verwendest, kannst du einen Workflow so konfigurieren, dass er auf bestimmten Branches oder Tags ausgeführt wird.\n\nVerwende 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.\n\nVerwende 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.\n\nWenn 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.\n\nDie 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).\n\n#### Beispiel: Einschließen von Branches und Tags\n\nDie 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:\n\n* Ein Branch namens `main` (`refs/heads/main`)\n* Ein Branch namens `mona/octocat` (`refs/heads/mona/octocat`)\n* Ein Branch, dessen Name mit `releases/` beginnt, wie `releases/10` (`refs/heads/releases/10`)\n* Ein Tag namens `v2` (`refs/tags/v2`)\n* Ein Tag, dessen Name mit `v1.` beginnt, wie `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n#### Beispiel: Ausschließen von Branches und Tags\n\nWenn 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:\n\n* Ein Branch namens `mona/octocat` (`refs/heads/mona/octocat`)\n* Ein Branch, dessen Name mit `releases/**-alpha` übereinstimmt, wie `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* Ein Tag namens `v2` (`refs/tags/v2`)\n* Ein Tag, dessen Name mit `v1.` beginnt, wie `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n#### Beispiel: Einschließen und Ausschließen von Branches und Tags\n\nDu 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.\n\nWenn 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`.\n\nDie Reihenfolge, in der Du die Muster definierst, ist entscheidend.\n\n* Ein passendes negatives Muster (mit dem Präfix `!`) nach einer positiven Übereinstimmung schließt den Verweis auf Git aus.\n* Ein übereinstimmendes positives Muster nach einem negativen Abgleich schließt die Git-Ref wieder ein.\n\nDer 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Verwenden von Filtern, um spezifische Pfade als Ziel für Pull Request- oder Pushereignisse festzulegen\n\nWenn 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.\n\nVerwende 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.\n\n> \\[!NOTE]\n> Die Reihenfolge, in der `paths`-Muster definiert werden, ist entscheidend:\n>\n> * Ein passendes negatives Muster, dem nach einer positiven Übereinstimmung `!` vorangestellt ist, schließt den Pfad aus.\n> * Ein passendes positives Muster nach einem negativen Abgleich schließt den Pfad wieder ein.\n\nWenn du sowohl `branches`/`branches-ignore` als auch `paths`/`paths-ignore` definierst, wird der Workflow nur ausgeführt, wenn beide Filter zutreffen.\n\nDie 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).\n\n#### Beispiel: Einbeziehen von Pfaden\n\nWenn 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.\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nWenn 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.\n\n#### Beispiel: Ausschließen von Pfaden\n\nWenn 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.\n\nEin 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.\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n#### Beispiel: Einschließen und Ausschließen von Pfaden\n\nDu 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.\n\nWenn 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`.\n\nDie Reihenfolge, in der `paths`-Muster definiert werden, ist entscheidend:\n\n* Ein passendes negatives Muster mit dem Präfix `!` nach einem positiven Abgleich schließt den Pfad aus.\n* Ein passendes positives Muster nach einem negativen Abgleich schließt den Pfad wieder ein.\n\nIn 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.\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n#### Git-Diff-Vergleiche\n\nUm 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.\n\nGitHub generiert die Liste der geänderten Dateien mithilfe von Zwei-Punkt-Diffs für Pushes und Drei-Punkt-Diffs für Pull Requests:\n\n* **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.\n* **Pushes in vorhandene Branches:** Ein Zwei-Punkte-Diff vergleicht die Head- und Basis-SHAs direkt miteinander.\n* **Pushes in neue Branches:** Ein Zwei-Punkte-Diff gegen das übergeordnete Element des Vorgängers des tiefsten gepushten Commits.\n\nIn einigen Situationen wendet GitHub Actions Beschränkungen an, die ändern, wie gefilterte Workflows ausgeführt werden:\n\n* Wenn ein Push mehr als 1.000 Commits enthält, wird der Workflow **immer** ausgeführt.\n* Wenn beim Generieren des Diffs ein Timeout auftritt, wird der Workflow **immer** ausgeführt.\n* 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.\n\nWenn 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.\n\nWeitere Informationen finden Sie unter [Branches](/de/pull-requests/reference/branches).\n\n### Verwenden von Filtern, um spezifische Branches als Ziel für Workflowausführungsereignisse festzulegen\n\nWenn 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.\n\nDie 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).\n\nBeispielsweise wird ein Workflow mit dem folgenden Trigger nur ausgeführt, wenn der Workflow namens `Build` in einem Branch namens `releases/` ausgeführt wird.\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\nEin 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:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\nDu 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.\n\nDie Reihenfolge, in der Du die Muster definierst, ist entscheidend.\n\n* Ein passendes negatives Muster (Präfix `!`) nach einem positiven Abgleich schließt die Branch aus.\n* Ein passendes positives Muster nach einem negativen Abgleich schließt die Branch wieder ein.\n\nBeispielsweise 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## Definieren von Eingaben für manuell ausgelöste Workflows\n\nBei Verwendung des `workflow_dispatch`-Ereignisses kannst du optional Eingaben angeben, die an den Workflow übergeben werden.\n\nDieser Trigger empfängt nur Ereignisse, wenn sich die Workflow-Datei auf dem Standardbranch befindet.\nDer 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).\n\n> \\[!NOTE]\n>\n> * 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.\n> * Die maximale Anzahl von `inputs` Eigenschaften auf oberster Ebene ist 25 .\n> * Die maximale Länge der Nutzdaten für `inputs` beträgt 65.535 Zeichen.\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## Definieren von Eingaben, Ausgaben und Geheimnissen für wiederverwendbare Workflows\n\nDu 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).\n\n## Verwenden von Ereignisinformationen\n\nIm `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.\n\n### Anzeigen aller Eigenschaften eines Ereignisses\n\nIn 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).\n\nDu 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:\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### Zugreifen auf und Verwenden von Ereigniseigenschaften\n\nDu 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.\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          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.'\n```\n\nWeitere 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.\n\n## Erweiterte Steuerung der Workflow-Ausführung\n\nWenn 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.\n\n### Verwenden von Bedingungen\n\nDu kannst Bedingungen verwenden, um genauer zu steuern, ob Aufträge oder Schritte in deinem Workflow ausgeführt werden sollen.\n\n#### Beispiel für die Verwendung eines Werts in der Ereignisnutzlast\n\nWenn 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.\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### Beispiel für die Verwendung eines Ereignistyps\n\nWenn 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`.\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\nWeitere 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).\n\n### Verwenden von Umgebungen zum manuellen Auslösen von Workflowaufträgen\n\nWenn 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.\n\nDer 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`).\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> 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.\n> 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.\n\n## Verfügbare Ereignisse\n\nEine 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)."}