Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
Informationen zu Workflowtriggern
Workflowtrigger sind Ereignisse, die dazu führen, dass ein Workflow ausgeführt wird. Dabei kann es sich um folgende Ereignisse handeln:
- Ereignisse, die im Repository deines Workflows auftreten
- Ereignisse, die außerhalb von GitHub Enterprise Server auftreten und ein
repository_dispatch
-Ereignis in GitHub Enterprise Server auslösen - Geplante Zeiten
- Manuell
Du kannst deinen Workflow so konfigurieren, dass er ausgeführt wird, wenn ein Push an den Standardzweig deines Repositorys durchgeführt, ein Release erstellt oder ein Issue geöffnet wird.
Workflowtrigger werden mit dem Schlüssel on
definiert. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:
-
In deinem Repository tritt ein Ereignis auf. Dem Ereignis sind ein Commit-SHA und ein Git-Verweis zugeordnet.
-
GitHub Enterprise Server durchsucht das Verzeichnis
.github/workflows
in deinem Repository nach Workflowdateien, die im zugehörigen Commit-SHA oder Git-Verweis des Ereignisses vorhanden sind. -
Für alle Workflows, die über
on:
-Werte verfügen, die mit dem auslösenden Ereignis übereinstimmen, wird eine Workflowausführung ausgelöst. Bei einigen Ereignissen muss die Workflowdatei außerdem im Standardbranch des Repositorys vorhanden sein, damit eine Ausführung möglich ist.Bei jeder Ausführung des Workflows wird die Workflowversion verwendet, die im zugehörigen Commit-SHA oder Git-Verweis des Ereignisses enthalten ist. Wenn ein Workflow ausgeführt wird, legt GitHub Enterprise Server die Umgebungsvariablen
GITHUB_SHA
(Commit-SHA) undGITHUB_REF
(Git-Verweis) in der Runnerumgebung fest. Weitere Informationen findest du unter Variablen.
Auslösen eines Workflows aus einem Workflow
Wenn Sie das GITHUB_TOKEN
des Repositorys zum Ausführen von Tasks verwenden, erstellen Ereignisse, die von GITHUB_TOKEN
keine neue Workflowausführung. 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 Automatische Tokenauthentifizierung.
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 findest du 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 Erstellen eines persönlichen Zugriffstokens. Weitere Informationen zum Speichern von Geheimnissen findest du unter Verschlüsselte Geheimnisse.
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:
GITHUB_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:
GITHUB_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 über Ereignisse, 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, wiereleases/10
(refs/heads/releases/10
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
Beispiel: Ausschließen von Branches
Wenn ein Muster dem Muster branches-ignore
entspricht, wird der Workflow nicht ausgeführt. Die in branches
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, wiereleases/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-ignore
definierst, wird der Workflow nicht für Ereignisse ausgeführt, die sich auf die nicht definierten Git-Verweise auswirken. Wenn du weder tags
/tags-ignore
noch branches
/branches-ignore
definierst, wird der Workflow für Ereignisse ausgeführt, die sich entweder auf Branches oder Tags auswirken. 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, wiereleases/10
(refs/heads/releases/10
) - Ein Tag namens
v2
(refs/tags/v2
) - Ein Tag, dessen Name mit
v1.
beginnt, wiev1.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, wiebeta/3-alpha
(refs/releases/beta/3-alpha
) - Ein Tag namens
v2
(refs/tags/v2
) - Ein Tag, dessen Name mit
v1.
beginnt, wiev1.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 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'
Hinweis: 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. Weitere Informationen findest du unter Fehlerbehebung von erforderlichen Statuschecks.
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 du Pfadmuster für ein einzelnes Ereignis sowohl einschließen als auch ausschließen möchtest, verwende den Filter paths
zusammen mit dem 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 du Muster definierst, 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
Hinweis: Wenn der Push-Vorgang mehr als 1.000 Commits umfasst oder wenn GitHub die Diff wegen einer Zeitüberschreitung nicht erzeugt, wird der Workflow immer ausgeführt.
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.
Diffs sind auf 300 Dateien beschränkt. Wenn Dateien geändert werden, die nicht mit den ersten 300 vom Filter zurückgegebenen Dateien übereinstimmen, wird der Workflow nicht ausgeführt. Du musst eventuell genauere Filter erstellen, damit der Workflow automatisch ausgeführt wird.
Weitere Informationen findest du 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. Der ausgelöste Workflow empfängt die Eingaben im inputs
-Kontext. Weitere Informationen findest du unter Kontexte.
Hinweis: 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.
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 findest du unter [AUTOTITLE](/actions/using-workflows/reusing-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 findest du unter [AUTOTITLE](/webhooks-and-events/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 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:
GITHUB_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 Kontexte. 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 zur Verwendung von Bedingungen findest du unter Ausdrücke.
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 findest du unter Verwenden 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
echo 'building'
publish:
needs: [build]
runs-on: ubuntu-latest
environment: production
steps:
- name: publish
echo 'publishing'
Umgebungen, Umgebungsgeheimnisse und Umgebungsschutzregeln sind in öffentlichen Repositorys für alle Produkte verfügbar. Für den Zugriff auf Umgebungen, Umgebungsgeheimnisse und Bereitstellungsbranches in privaten oder internen Repositorys musst du GitHub Pro, GitHub Team oder GitHub Enterprise verwenden. Für den Zugriff auf andere Umgebungsschutzregeln in privaten oder internen Repositorys musst du GitHub Enterprise verwenden.
Verfügbare Ereignisse
Eine vollständige Liste der verfügbaren Ereignisse findest du unter Ereignisse zum Auslösen von Workflows.