Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
Informationen zur YAML-Syntaxs für Workflows
Workflow-Dateien verwenden die YAML-Syntax und müssen die Dateierweiterung .yml
oder .yaml
aufweisen. If you're new to YAML and want to learn more, see "Learn YAML in Y minutes."
Workflow-Dateien müssen im Verzeichnis .github/workflows
im Repository gespeichert werden.
name
Name des Workflows. GitHub zeigt die Namen Deiner Workflows auf der Aktionen-Seite Deines Repositorys an. Wenn Du name
weglässt, setzt GitHub den Pfad der Workflow-Datei relativ zum Stammverzeichnis des Repositorys.
on
Required. The name of the GitHub event that triggers the workflow. Sie können einen string
für ein einzelnes Ereignis, ein array
mit Ereignissen, ein array
mit Ereignis-types
oder eine Ereigniskonfigurations-map
festlegen, mit der ein Workflow geplant oder die Ausführung eines Workflows auf bestimmte Dateien, Tags oder Branch-Änderungen beschränkt wird. Eine Liste der verfügbaren Ereignisse finden Sie unter „Ereignisse, die Workflows auslösen“.
Example: Using a single event
# Triggered when code is pushed to any branch in a repository
on: push
Example: Using a list of events
# Triggers the workflow on push or pull request events
on: [push, pull_request]
Example: Using multiple events with activity types or configuration
Wenn Du Aktivitätstypen oder Konfigurationen für ein Ereignis angeben musst, musst Du jedes Ereignis separat konfigurieren. Du musst einen Doppelpunkt (:
) an alle Ereignisse anhängen, einschließlich Ereignisse ohne Konfiguration.
on:
# Trigger the workflow on push or pull request,
# but only for the main branch
push:
branches:
- main
pull_request:
branches:
- main
# Also trigger on page_build, as well as release created events
page_build:
release:
types: # This configuration does not affect the page_build event above
- created
on.<event_name>.types
Legt die Aktivitätstypen fest, die die Ausführung eines Workflows auslösen. Die meisten GitHub-Ereignisse werden von mehreren Aktivitätstypen ausgelöst. Beispielsweise wird das Ereignis für die Veröffentlichungsressource ausgelöst, wenn eine Veröffentlichung veröffentlicht (published
), erstellt (created
), bearbeitet (edited
), gelöscht (deleted
), vorab veröffentlicht (prereleased
) oder ihre Veröffentlichung zurückgezogen (unpublished
) wird. Mit dem Stichwort types
grenzt Du die Aktivitäten ein, die die Ausführung des Workflows auslösen. Wird ein Webhook-Ereignis nur von einem einzigen Aktivitätstyp ausgelöst, ist das Stichwort types
nicht erforderlich.
Du kannst ein Array mit Ereignis-types
benutzen. Weitere Informationen zu den einzelnen Ereignissen und den zugehörigen Aktivitätstypen findest Du unter „Ereignisse, die Workflows auslösen“.
# Trigger the workflow on release activity
on:
release:
# Only use the types keyword to narrow down the activity types that will trigger your workflow.
types: [published, created, edited]
on.<push|pull_request>.<branches|tags>
Wenn Sie die Ereignisse push
und pull_request
verwenden, können Sie einen Workflow so konfigurieren, dass er auf bestimmten Branches oder Tags ausgeführt wird. Für ein pull_request
-Ereignis werden nur Branches und Tags auf der Basis ausgewertet. Wenn Du nur tags
oder nur branches
definierst, wird der Workflow bei Ereignissen, die sich auf die nicht definierte Git-Ref auswirken, nicht ausgeführt.
The branches
, branches-ignore
, tags
, and tags-ignore
keywords accept glob patterns that use characters like *
, **
, +
, ?
, !
and others to match more than one branch or tag name. If a name contains any of these characters and you want a literal match, you need to escape each of these special characters with \
. For more information about glob patterns, see the "Filter pattern cheat sheet."
Example: Including branches and tags
Die in branches
und tags
definierten Muster werden anhand des Namens des Git-Ref ausgewertet. Wenn Du das Muster mona/octocat
in branches
definierst, passt beispielsweise die Git-Ref refs/heads/mona/octocat
. Zu dem Muster releases/**
passt die Git-Ref refs/heads/releases/10
.
on:
push:
# Sequence of patterns matched against refs/heads
branches:
# Push events on main branch
- main
# Push events to branches matching refs/heads/mona/octocat
- 'mona/octocat'
# Push events to branches matching refs/heads/releases/10
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v1 # Push events to v1 tag
- v1.* # Push events to v1.0, v1.1, and v1.9 tags
Example: Ignoring branches and tags
Wenn ein Muster mit dem Muster branches-ignore
oder tags-ignore
übereinstimmt, wird der Workflow nicht ausgeführt. Die in branches-ignore
und tags-ignore
definierten Muster werden anhand des Namens der Git-Ref ausgewertet. Wenn Du das Muster mona/octocat
in branches
definierst, passt beispielsweise die Git-Ref refs/heads/mona/octocat
. Das Muster releases/**-alpha
in branches
passt zu der Git-Ref refs/releases/beta/3-alpha
.
on:
push:
# Sequence of patterns matched against refs/heads
branches-ignore:
# Do not push events to branches matching refs/heads/mona/octocat
- 'mona/octocat'
# Do not push events to branches matching refs/heads/releases/beta/3-alpha
- 'releases/**-alpha'
# Sequence of patterns matched against refs/tags
tags-ignore:
- v1.* # Do not push events to tags v1.0, v1.1, and v1.9
Branches und Tags ausschließen
Es stehen zwei Arten von Filtern zur Verfügung, mit denen Du die Ausführung eines Workflows bei Push-Vorgängen und Pull-Requests an Tags und Branches unterbinden kannst.
branches
oderbranches-ignore
- Du kannst die beiden Filterbranches
undbranches-ignore
nicht gleichzeitig für dasselbe Ereignis in einem Workflow verwenden. Mit dem Filterbranches
kannst Du die Branches auf positive Übereinstimmungen filtern und Branches ausschließen. Nutze den Filterbranches-ignore
, wenn Du lediglich Branch-Namen ausschließen musst.tags
odertags-ignore
- Du kannst die beiden Filtertags
und den Filtertags-ignore
nicht gleichzeitig für dasselbe Ereignis in einem Workflow verwenden. Mit dem Filtertags
kannst Du die Tags auf positive Übereinstimmungen filtern und Tags ausschließen. Nutze den Filterbranches-ignore
, wenn Du lediglich Tag-Namen ausschließen musst.
Example: Using positive and negative patterns
Mit dem Zeichen !
kannst Du tags
und branches
ausschließen. Die Reihenfolge, in der Du die Muster definierst, ist entscheidend.
- Wenn eine Übereinstimmung mit einem negativen Muster (mit vorangestelltem
!
) nach einem positiven Abgleich vorliegt, wird die Git-Ref ausgeschlossen. - Ein übereinstimmendes positives Muster nach einem negativen Abgleich schließt die Git-Ref wieder ein.
Der folgende Workflow wird bei Push-Vorgängen an releases/10
oder releases/beta/mona
ausgeführt, nicht jedoch bei Push-Vorgängen an releases/10-alpha
oder releases/beta/3-alpha
, da das negative Muster !releases/**-alpha
nach dem positiven Muster steht.
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
on.<push|pull_request>.paths
Bei den Ereignissen push
und pull_request
kannst Du einen Workflows zur Ausführung konfigurieren, wenn mindestens eine Datei nicht zu den paths-ignore
passt oder mindestens eine geänderte Datei zu den konfigurierten paths
passt. Bei Push-Vorgängen zu Tags werden Pfadfilter nicht ausgewertet.
Unter den Schlüsselwörtern paths-ignore
und paths
kannst Du Glob-Muster nutzen, so dass mithilfe der Platzhalterzeichens *
und **
mehrere Pfadnamen passen. Weitere Informationen findest Du auf dem „Spickzettel zu Filtermustern“.
Example: Ignoring paths
When all the path names match patterns in paths-ignore
, the workflow will not run. GitHub wertet die in paths-ignore
definierten Muster anhand des Pfadnamens aus. Ein Workflow mit dem nachfolgenden Pfadfilter wird nur bei push
-Ereignissen ausgeführt, bei denen sich mindestens eine Datei außerhalb des Verzeichnisses docs
im Root des Repositorys befindet.
on:
push:
paths-ignore:
- 'docs/**'
Example: Including paths
Wenn mindestens ein Pfad zu einem Muster im Filter paths
passt, wird der Workflow ausgeführt. Soll bei jedem Push-Vorgang einer JavaScript-Datei ein Build ausgelöst werden, gibst Du ein Muster mit Platzhalterzeichen an.
on:
push:
paths:
- '**.js'
Pfade ausschließen
Pfade können mit zwei Arten von Filtern ausgeschlossen werden. Du kannst nicht beide Filter gleichzeitig für dasselbe Ereignis in einem Workflow nutzen.
paths-ignore
- Verwende den Filterpaths-ignore
, wenn Du lediglich Pfadnamen ausschließen musst.paths
- Mit dem Filterpaths
kannst Du die Pfade auf positive Übereinstimmungen filtern und Pfade ausschließen.
Example: Using positive and negative patterns
Mit dem Zeichen !
kannst Du paths
ausschließen. Die Reihenfolge, in der Sie Muster definieren, ist entscheidend:
- Wenn nach einem positiven Abgleich ein negatives Muster (mit vorangestelltem
!
) passt, wird der Pfad ausgeschlossen. - Ein passendes positives Muster nach einem negativen Abgleich schließt den Pfad wieder ein.
Dieses Beispiel wird stets ausgeführt, wenn das push
-Ereignis eine Datei im Verzeichnis sub-project
oder in einem Unterverzeichnis davon umfasst, jedoch nur dann, wenn sich die Datei nicht im Verzeichnis sub-project/docs
befindet. Ein Push-Vorgang, mit dem beispielsweise die Datei sub-project/index.js
oder sub-project/src/index.js
geändert wird, löst eine Ausführung des Workflows aus, aber ein Push-Vorgang, mit dem lediglich sub-project/docs/readme.md
geändert wird, tut dies nicht.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Git-Diff-Vergleiche
Note: If you push more than 1,000 commits, or if GitHub does not generate the diff due to a timeout, the workflow will always run.
Zur Ermittlung, ob ein Workflow ausgeführt werden soll, wertet der Filter die geänderten Dateien anhand der Liste 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 jüngsten Version des Themen-Branches und jenem Commit, bei welchem der Themen-Branch zuletzt mit dem Basis-Branch synchronisiert wurde.
- Push-Vorgänge an bestehende Branches: Eine Two-Dot-Diff vergleicht die Kopf- und Basis-SHAs direkt miteinander.
- Push-Vorgänge an neue Branches: Ein Two-Dot-Diff wird mit dem übergeordneten Element des Vorgängers des tiefsten gepushten Commits durchgeführt.
Diffs are limited to 300 files. If there are files changed that aren't matched in the first 300 files returned by the filter, the workflow will not run. You may need to create more specific filters so that the workflow will run automatically.
Weitere Informationen findest Du unter „Informationen zum Vergleich von Branches in Pull-Requests“.
on.workflow_dispatch.inputs
When using the workflow_dispatch
event, you can optionally specify inputs that are passed to the workflow. Workflow dispatch inputs are specified with the same format as action inputs. For more information about the format see "Metadata syntax for GitHub Actions."
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
tags:
description: 'Test scenario tags'
required: false
The triggered workflow receives the inputs in the github.event.inputs
context. Weitere Informationen finden Sie unter „Kontexte“.
on.schedule
Du kannst einen Workflow mit Hilfe von POSIX cron syntax so planen, dass er zu bestimmten UTC-Zeiten ausgeführt wird. Geplante Workflows laufen auf dem jüngsten Commit auf dem Standard- oder Basisbranch. Das kürzeste Intervall, in dem Sie geplante Workflows ausführen können, ist einmal alle 5 Minuten.
This example triggers the workflow every day at 5:30 and 17:30 UTC:
on:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '30 5,17 * * *'
Weitere Informationen zur Cron-Syntax findest Du unter „Ereignisse, die Workflows auslösen“.
env
A map
of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see jobs.<job_id>.env
and jobs.<job_id>.steps[*].env
.
Wenn mehr als eine Umgebungsvariable mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Umgebungsvariable. Beispielsweise wird eine in einem Schritt definierte Umgebungsvariable die Auftrags- und Workflow-Variablen mit dem gleichen Namen überschreiben, während der Schritt ausgeführt wird. Eine für einen Auftrag definierte Variable überschreibt die Workflow-Variable mit dem gleichen Namen, während der Auftrag ausgeführt wird.
Beispiel
env:
SERVER: production
defaults
Eine map
der Standardeinstellungen, die für alle Jobs im Workflow gelten. Du kannst auch Standardeinstellungen festlegen, die nur für einen Job verfügbar sind. Weitere Informationen findest Du unter jobs.<job_id>.defaults
.
Wenn mehr als eine Standardeinstellung mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Standardeinstellung. Beispielsweise wird eine in einem Auftrag definierte Standardeinstellung die gleichnamig definierte Standardeinstellung in einem Workflow überschreiben.
defaults.run
Du kannst Standardeinstellungen der Optionen shell
und working-directory
(Arbeitsverzeichnis) für alle run
-Schritte in einem Workflow angeben. Du kannst auch Standardeinstellungen für run
festlegen, die nur für einen Job verfügbar sind. Weitere Informationen findest Du unter jobs.<job_id>.defaults.run
. In diesem Schlüsselwort kannst Du keine Kontexte oder Ausdrücke verwenden.
Wenn mehr als eine Standardeinstellung mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Standardeinstellung. Beispielsweise wird eine in einem Auftrag definierte Standardeinstellung die gleichnamig definierte Standardeinstellung in einem Workflow überschreiben.
Beispiel
defaults:
run:
shell: bash
working-directory: scripts
jobs
Ein Workflow-Lauf besteht aus mindestens einem Auftrag. Die Aufträge werden standardmäßig parallel ausgeführt. Sollen Aufträge sequenziell ausgeführt werden, können Sie mit dem Stichwort jobs.<job_id>.needs
eine Abhängigkeit von anderen Aufträgen definieren.
Each job runs in a runner environment specified by runs-on
.
Innerhalb der Nutzungsbeschränkungen des Workflows kannst Du unbegrenzt viele Jobs ausführen. For more information, see "Usage limits and billing" for GitHub-hosted runners and "About self-hosted runners" for self-hosted runner usage limits.
Wenn Du den eindeutigen Bezeichner eines Jobs finden musst, der in einem Workflowlauf ausgeführt wird, kannst Du die API von GitHub verwenden. For more information, see "Workflow Jobs."
jobs.<job_id>
Jedem Auftrag muss eine ID zugewiesen sein. Das Stichwort job_id
ist ein String, und der Wert umfasst eine Zuordnung der Konfigurationsdaten für den Auftrag. Sie müssen <job_id>
durch einen eindeutigen String für das jobs
-Objekt ersetzen. Die <job_id>
muss mit einem Buchstaben oder einem Unterstrich (_
) beginnen und darf nur alphanumerische Zeichen, Bindestriche (-
) und Unterstriche (_
) enthalten.
Beispiel
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
jobs.<job_id>.name
Name des Auftrags, der auf GitHub angezeigt wird.
jobs.<job_id>.needs
Liste mit allen Aufträgen, die erfolgreich abgeschlossen sein müssen, bevor dieser Auftrag ausgeführt wird. Hier ist ein String oder ein Array mit Strings zulässig. If a job fails, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue.
Example: Requiring dependent jobs to be successful
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
In diesem Beispiel muss job1
erfolgreich abgeschlossen werden, bevor job2
beginnt, und job3
wartet ab, bis sowohl job1
als auch job2
abgeschlossen sind.
Die Aufträge in diesem Beispiel werden sequenziell ausgeführt:
job1
job2
job3
Example: Not requiring dependent jobs to be successful
jobs:
job1:
job2:
needs: job1
job3:
if: always()
needs: [job1, job2]
In this example, job3
uses the always()
conditional expression so that it always runs after job1
and job2
have completed, regardless of whether they were successful. For more information, see "Expressions."
jobs.<job_id>.runs-on
Required. The type of machine to run the job on. Die Maschine kann entweder ein GitHub-gehosteter oder ein selbst-gehosteter Runner sein.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
GitHub-gehostete Runner
Wenn Du einen GitHub-gehosteten Runner verwendest, läuft jeder Job in einer frischen Instanz einer virtuellen Umgebung, die mit runs-on
angegeben wurde.
Verfügbare Arten von GitHub-gehostete Runnern sind:
Virtuelle Umgebung | YAML-Workflow-Kennzeichnung | Hinweise: |
---|---|---|
Windows Server 2022[beta] | windows-2022 |
The windows-latest label currently uses the Windows Server 2019 runner image.
|
Windows Server 2019 | windows-latest oder windows-2019 |
|
Windows Server 2016 | windows-2016 |
|
Ubuntu 20.04 | ubuntu-latest oder ubuntu-20.04 |
|
Ubuntu 18.04 | ubuntu-18.04 |
|
macOS Big Sur 11 | macos-11 |
The macos-latest label currently uses the macOS 10.15 runner image.
|
macOS Catalina 10.15 | macos-latest or macos-10.15 |
Note: Beta Images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. Beta Images may not be covered by customer support.
Beispiel
Runs-on: ubuntu-latest
Weitere Informationen findest Du unter "Virtuelle Umgebungen für GitHub-gehostete Runner."
Selbst-gehostete Runner
Um einen selbst-gehosteten Läufer für Deinen Auftrag anzugeben, konfiguriere runs-on
in Deiner Workflow-Datei mit selbst gehosteten Läuferkennzeichnungen.
All self-hosted runners have the self-hosted
label. Using only this label will select any self-hosted runner. To select runners that meet certain criteria, such as operating system or architecture, provide an array of labels that begins with self-hosted
(this must be listed first) and then includes additional labels as needed.
Beispiel
runs-on: [self-hosted, linux]
Weitere Informationen findest Du unter „Informationen zu selbst-gehosteten Runnern“ und „Selbst-gehostete Runner in einem Workflow verwenden“.
jobs.<job_id>.outputs
Eine map
der Ausgaben eines Jobs. Ausgaben eines Jobs stehen allen nachgelagerten Jobs zur Verfügung, die von diesem Job abhängen. Weitere Informationen zur Definition von Abhängigkeiten zwischen Jobs findest Du unter Jobs.<job_id>.needs
.
Ausgaben von Jobs sind Zeichenketten und wenn sie Ausdrücke enthalten, werden diese am Ende jedes Jobs auf dem Runner ausgewertet. Ausgaben, die Geheimnisse enthalten, werden auf dem Runnder zensiert und nicht an GitHub Actions gesendet.
Um Jobausgaben in einem abhängigen Job zu verwenden, kannst Du den Kontext needs
verwenden. Weitere Informationen finden Sie unter „Kontexte“.
Beispiel
jobs:
job1:
runs-on: ubuntu-latest
# Map a step output to a job output
outputs:
output1: ${{ steps.step1.outputs.test }}
output2: ${{ steps.step2.outputs.test }}
steps:
- id: step1
run: echo "::set-output name=test::hello"
- id: step2
run: echo "::set-output name=test::world"
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}
jobs.<job_id>.env
Eine map
mit Umgebungsvariablen, die für alle Schritte im Auftrag verfügbar sind. Darüber hinaus können Sie Umgebungsvariablen für den gesamten Workflow oder für einen einzelnen Schritt festlegen. For more information, see env
and jobs.<job_id>.steps[*].env
.
Wenn mehr als eine Umgebungsvariable mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Umgebungsvariable. Beispielsweise wird eine in einem Schritt definierte Umgebungsvariable die Auftrags- und Workflow-Variablen mit dem gleichen Namen überschreiben, während der Schritt ausgeführt wird. Eine für einen Auftrag definierte Variable überschreibt die Workflow-Variable mit dem gleichen Namen, während der Auftrag ausgeführt wird.
Beispiel
jobs:
job1:
env:
FIRST_NAME: Mona
jobs.<job_id>.defaults
Eine map
mit Standardeinstellungen, die für alle Schritte im Job gelten. Du kannst auch Standardeinstellungen für den gesamten Workflow festlegen. Weitere Informationen findest Du unter Standardwerte
.
Wenn mehr als eine Standardeinstellung mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Standardeinstellung. Beispielsweise wird eine in einem Auftrag definierte Standardeinstellung die gleichnamig definierte Standardeinstellung in einem Workflow überschreiben.
jobs.<job_id>.defaults.run
Standards für shell
und working-directory
(Arbeitsverzeichnis) bereitstellen, die für alle run
-Schritte des Jobs gelten. Kontext und Ausdruck sind in diesem Abschnitt nicht zulässig.
Du kannst Standardeinstellungen der Optionen shell
und working-directory
(Arbeitsverzeichnis) für alle run
-Schritte in einem Job angeben. Du kannst auch Standardeinstellungen für run
für den gesamten Workflow festlegen. Weitere Informationen findest Du unter jobs.defaults.run
. In diesem Schlüsselwort kannst Du keine Kontexte oder Ausdrücke verwenden.
Wenn mehr als eine Standardeinstellung mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Standardeinstellung. Beispielsweise wird eine in einem Auftrag definierte Standardeinstellung die gleichnamig definierte Standardeinstellung in einem Workflow überschreiben.
Beispiel
jobs:
job1:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
working-directory: scripts
jobs.<job_id>.if
Mit der if
-Bedingung geben Sie an, dass ein Auftrag nur dann ausgeführt werden soll, wenn eine bestimmte Bedingung erfüllt ist. Sie können eine Bedingung mit jedem unterstützten Kontext und Ausdruck erstellen.
Wenn Du Ausdrücke in einer if
Bedingung verwendest, kannst Du die Syntax des Ausdrucks (${{ }}
) weglassen, da GitHub automatisch die if
Bedingung als Ausdruck wertet. For more information, see "Expressions."
jobs.<job_id>.steps
Ein Auftrag enthält eine Sequenz von Aufgaben, sogenannten steps
. Mit Schritten können Befehle oder Einrichtungsaufgaben ausgeführt werden, und außerdem Aktionen, die sich in Ihrem Repository oder in einem öffentlichen Repository befinden oder in einer Docker Registry veröffentlicht sind. Nicht alle Schritte führen Aktionen aus, doch alle Aktionen werden als Schritt ausgeführt. Jeder Schritt wird in einem eigenen Prozess in der Runner-Umgebung ausgeführt. Er hat Zugriff auf den Arbeitsbereich und das Dateisystem. Da die Schritte jeweils in einem eigenen Prozess laufen, werden Änderungen an den Umgebungsvariablen nicht von einem Schritt zum nächsten beibehalten. GitHub umfasst integrierte Schritte zum Einrichten und Ausführen eines Auftrags.
Innerhalb der Nutzungsbeschränkungen des Workflows kannst Du unbegrenzt viele Schritte ausführen. For more information, see "Usage limits and billing" for GitHub-hosted runners and "About self-hosted runners" for self-hosted runner usage limits.
Beispiel
name: Greeting from Mona
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- name: Print a greeting
env:
MY_VAR: Hi there! My name is
FIRST_NAME: Mona
MIDDLE_NAME: The
LAST_NAME: Octocat
run: |
echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
jobs.<job_id>.steps[*].id
Eine eindeutige Kennung für den Schritt. Anhand der id
können Sie in Kontexten auf den Schritt verweisen. Weitere Informationen finden Sie unter „Kontexte“.
jobs.<job_id>.steps[*].if
Mit der Bedingung if
gibst Du an, dass ein Schritt nur dann ausgeführt werden soll, wenn eine bestimmte Bedingung erfüllt ist. Sie können eine Bedingung mit jedem unterstützten Kontext und Ausdruck erstellen.
Wenn Du Ausdrücke in einer if
Bedingung verwendest, kannst Du die Syntax des Ausdrucks (${{ }}
) weglassen, da GitHub automatisch die if
Bedingung als Ausdruck wertet. For more information, see "Expressions."
Example: Using contexts
Dieser Schritt wird nur ausgeführt, wenn das Ereignis vom Typ pull_request
und die Ereignisaktion unassigned
ist.
steps:
- name: My first step
if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
run: echo This event is a pull request that had an assignee removed.
Example: Using status check functions
my backup step
wird nur dann ausgeführt, wenn der vorherige Schritt eines Auftrags fehlschlägt. For more information, see "Expressions."
steps:
- name: My first step
uses: octo-org/action-name@main
- name: My backup step
if: ${{ failure() }}
uses: actions/heroku@1.0.0
jobs.<job_id>.steps[*].name
Name des Schritts, der auf GitHub angezeigt wird.
jobs.<job_id>.steps[*].uses
Wählt eine Aktion aus, die als Teil eines Schritts im Job ausgeführt wird. Eine Aktion ist eine wiederverwendbare Code-Einheit. Du kannst eine Aktion verwenden, die im selben Repository wie der Workflow, in einem öffentlichen Repository oder in einem veröffentlichten Docker-Container-Image definiert ist.
Es wird dringend empfohlen, die verwendete Version der Aktion zu nennen (Git-Ref, SHA oder Docker-Tag-Nummer angeben). Wenn Du keine Version angibst, könnten damit die Workflows gestört werden, oder es wird ein unerwartetes Verhalten hervorgerufen, wenn der Inhaber der Aktion eine Aktualisierung veröffentlicht.
- Am besten in Hinblick auf Stabilität und Sicherheit ist es, die Commit-SHA einer freigegebenen Version einer Aktion zu verwenden.
- Wenn Du Dich auf die Hauptversion der Aktion beziehst, kannst Du kritische Fehlerbehebungen und Sicherheits-Patches erhalten und gleichzeitig die Kompatibilität wahren. Außerdem ist damit sichergestellt, dass der Workflow weiterhin problemlos arbeiteten sollte.
- Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.
Für einige Aktionen sind Eingaben erforderlich, die Du mit dem Schlüsselwort with
festlegen musst. Die erforderlichen Eingaben findest Du in der README-Datei der Aktion.
Aktionen sind entweder JavaScript-Dateien oder Docker-Container. Bei Docker-Containern als Aktion mmusst Du den Job in einer Linux-Umgebung ausführen. Weitere Details findest Du unter runs-on
.
Example: Using versioned actions
steps:
# Reference a specific commit
- uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout@v2
# Reference a specific version
- uses: actions/checkout@v2.2.0
# Reference a branch
- uses: actions/checkout@main
Example: Using a public action
{owner}/{repo}@{ref}
You can specify a branch, ref, or SHA in a public GitHub repository.
jobs:
my_first_job:
steps:
- name: My first step
# Uses the default branch of a public repository
uses: actions/heroku@main
- name: My second step
# Uses a specific version tag of a public repository
uses: actions/aws@v2.0.1
Example: Using a public action in a subdirectory
{owner}/{repo}/{path}@{ref}
Ein Unterverzeichnis in einem öffentlichen Repository auf GitHub in einem bestimmten Branch, einem bestimmten Ref oder einer bestimmten SHA.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/aws/ec2@main
Example: Using an action in the same repository as the workflow
./path/to/dir
Der Pfad zum Verzeichnis, das die Aktion im Repository Deines Workflows enthält. Du musst Dein Repository auschecken, bevor Du die Aktion verwendest.
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
- name: Use local my-action
uses: ./.github/actions/my-action
Example: Using a Docker Hub action
docker://{image}:{tag}
Ein Docker-Image, das auf Docker Hub veröffentlicht ist.
jobs:
my_first_job:
Schritte:
- Name: Mein erster Schritt
verwendet: docker://alpine:3.8
Example: Using a Docker public registry action
docker://{host}/{image}:{tag}
Ein Docker-Image in einer öffentlichen Registry. This example uses the Google Container Registry at gcr.io
.
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://gcr.io/cloud-builders/gradle
Example: Using an action inside a different private repository than the workflow
Your workflow must checkout the private repository and reference the action locally. Generate a personal access token and add the token as an encrypted secret. For more information, see "Creating a personal access token" and "Encrypted secrets."
Replace PERSONAL_ACCESS_TOKEN
in the example with the name of your secret.
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
with:
repository: octocat/my-private-repo
ref: v1.0
token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
path: ./.github/actions/my-private-repo
- name: Run my action
uses: ./.github/actions/my-private-repo/my-action
jobs.<job_id>.steps[*].run
Führt Befehlszeilen-Programme über die Betriebssystem-Shell aus. Wenn Du keinen name
angibst, wird standardmäßig der im Befehl run
angegebene Text als Name für den Schritt übernommen.
Befehle greifen standardmäßig auf Shells zurück, für die keine Anmeldung erforderlich ist. Du kannst für die Ausführung von Befehlen eine andere Shell auswählen und die Shell anpassen. Weitere Informationen findest Du unter „Bestimmte Shell verwenden“.
Jedes Schlüsselwort run
stellt einen neuen Prozess und eine neue Shell in der Runnerumgebung dar. Wenn Du mehrzeilige Befehle angibst, werden alle Zeilen in derselben Shell ausgeführt. Ein Beispiel:
-
Einzeiliger Befehl:
- name: Install Dependencies run: npm install
-
Mehrzeiliger Befehl:
- name: Clean install dependencies and build run: | npm ci npm run build
Mit dem Schlüsselwortworking-directory
gibst Du das Arbeitsverzeichnis an, in dem der Befehl ausgeführt werden soll.
- name: Clean temp directory
run: rm -rf *
working-directory: ./temp
Bestimmte Shell verwenden
Du kannst die Einstellungen zur Standard-Shell im Betriebssystem des Läufers mit dem Schlüsselwort shell
überschreiben. Du kannst die integrierten shell
-Schlüsselwörter verwenden oder eine benutzerdefinierte Menge von Shell-Optionen festlegen. The shell command that is run internally executes a temporary file that contains the commands specifed in the run
keyword.
Unterstützte Plattform | Parameter shell | Beschreibung | Intern ausgeführter Befehl |
---|---|---|---|
Alle | bash | Die standardmäßige Shell für alle Plattformen außer Windows mit einem Fallback zu sh . Wenn eine Bash-Shell für Windows angegeben wird, wird die in Git für Windows enthaltene Bash-Shell verwendet. | bash --noprofile --norc -eo pipefail {0} |
Alle | pwsh | Der PowerShell Core. GitHub hängt die Erweiterung .ps1 an Deinen Skriptnamen an. | pwsh -command ". '{0}'" |
Alle | python | Führt den Befehl Python aus. | python {0} |
Linux / macOS | sh | Das Fallback-Verhalten für alle Betriebssystem-Plattformen außer Windows, falls keine Shell angegeben ist und bash nicht im Pfad gefunden wird. | sh -e {0} |
Windows | cmd | GitHub hängt die Erweiterung .cmd an Deinen Skriptnamen an und ersetzt {0} . | %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"" . |
Windows | pwsh | Dies ist die standardmäßig für Windows verwendete Shell. Der PowerShell Core. GitHub hängt die Erweiterung .ps1 an Deinen Skriptnamen an. If your self-hosted Windows runner does not have PowerShell Core installed, then PowerShell Desktop is used instead. | pwsh -command ". '{0}'" . |
Windows | powershell | The PowerShell Desktop. GitHub hängt die Erweiterung .ps1 an Deinen Skriptnamen an. | powershell -command ". '{0}'" . |
Example: Running a script using bash
steps:
- name: Display the path
run: echo $PATH
shell: bash
Example: Running a script using Windows cmd
steps:
- name: Display the path
run: echo %PATH%
shell: cmd
Example: Running a script using PowerShell Core
steps:
- name: Display the path
run: echo ${env:PATH}
shell: pwsh
Example: Using PowerShell Desktop to run a script
steps:
- name: Display the path
run: echo ${env:PATH}
shell: powershell
Example: Running a python script
steps:
- name: Display the path
run: |
import os
print(os.environ['PATH'])
shell: python
Benutzerdefinierte Shell
Mit command […options] {0} [..more_options]
kannst Du einen Vorlagen-String für den Wert shell
festlegen. GitHub interpretiert das erste Wort im String, nach dem ein Leerzeichen steht, als Befehl, und der Dateiname für das temporäre Skript wird in {0}
eingefügt.
Ein Beispiel:
steps:
- name: Display the environment variables and their values
run: |
print %ENV
shell: perl {0}
The command used, perl
in this example, must be installed on the runner.
For information about the software included on GitHub-hosted runners, see "Specifications for GitHub-hosted runners."
Exit-Codes und Voreinstellung für Fehleraktionen
Für integrierte Shell-Stichwörter gelten die folgenden Standards, die durch auf GitHub gehostete Runner ausgeführt werden. Beachte diese Richtlinien beim Ausführen von Shell-Skripts.
-
bash
/sh
:- Fail-fast behavior using
set -eo pipefail
: Default forbash
and built-inshell
. Dies ist außerdem der Standard, wenn Du eine Option für eine Plattform außer Windows angibst. - Wenn Du auf Fail-Fast verzichtest und stattdessen die volle Kontrolle übernehmen möchtest, stelle einen Vorlagen-String für die Shell-Optionen bereit. Beispiel:
bash {0}
. - sh-ähnliche Shells liefern beim Beenden als ihren eigenen Exit-Code den Exit-Code des letzten Befehls, der im Skript ausgeführt wurde. Dies ist auch das Standardverhalten für Aktionen. Der Runner meldet den Status des Schritts gemäß diesem Exit-Code als Fehler/Erfolg.
- Fail-fast behavior using
-
powershell
/pwsh
- Fail-Fast-Verhalten, soweit möglich. Bei
pwsh
und der integrierten Shellpowershell
setzen wir$ErrorActionPreference = 'stop'
vor den Inhalt des Skripts. - An Powershell-Skripte hängen wir
if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }
an, sodass der Status der Aktionen den letzten Exit-Code im Skript wiedergibt. - Die Benutzer können jederzeit auf die integrierte Shell verzichten und eine benutzerdefinierte Shell-Option angeben, beispielsweise
pwsh -File {0}
oderpowershell -Command "& '{0}'"
, je nach Bedarf.
- Fail-Fast-Verhalten, soweit möglich. Bei
-
cmd
- Wenn Du das Fail-Fast-Verhalten uneingeschränkt nutzen möchtest, hast Du anscheinend keine andere Wahl, als Dein Skript so zu schreiben, dass jeder Fehlercode geprüft und eine entsprechende Reaktion eingeleitet wird. Dieses Verhalten kann nicht standardmäßig bereitgestellt werden; Du musst es explizit in Dein Skript schreiben.
cmd.exe
will exit with the error level of the last program it executed, and it will return the error code to the runner. Dieses Verhalten ist intern mit dem vorherigen Standardverhalten vonsh
undpwsh
konsistent und ist der Standard fürcmd.exe
, weshalb dieses Verhalten unverändert bleibt.
jobs.<job_id>.steps[*].with
Eine map
der Eingabeparameter, die in der Aktion definiert sind. Jeder Eingabeparameter ist ein Schlüssel-Wert-Paar. Eingabeparameter werden als Umgebungsvariablen festgelegt. Die Variable erhält das Präfix INPUT_
und wird in Großbuchstaben umgewandelt.
Beispiel
Definiert die drei Eingabeparameter (first_name
, middle_name
und last_name
), die in der Aktion hello_world
definiert sind. Diese Eingabevariablen sind für die Aktion hello-world
als Umgebungsvariablen INPUT_FIRST_NAME
, INPUT_MIDDLE_NAME
und INPUT_LAST_NAME
zugänglich.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/hello_world@main
with:
first_name: Mona
middle_name: The
last_name: Octocat
jobs.<job_id>.steps[*].with.args
Ein string
, der die Eingaben für einen Docker-Container definiert. Beim Start des Containers übergibt GitHub die args
-Anweisung an den ENTRYPOINT
des Containers. Ein array of strings
wird von diesem Parameter nicht unterstützt.
Beispiel
steps:
- name: Explain why this job ran
uses: octo-org/action-name@main
with:
entrypoint: /bin/echo
args: The ${{ github.event_name }} event triggered this step.
Die args
-Anweisungen werden anstelle der CMD
-Anweisung in einem Dockerfile
verwendet. Falls Sie CMD
in Ihrem Dockerfile
verwenden, sollten Sie sich an die nach Präferenz angeordneten Richtlinien halten:
- Dokumentiere die erforderlichen Argumente in der README der Aktion und lasse sie in der
CMD
-Anweisung weg. - Verwenden Sie Standardwerte, die die Verwendung der Aktion ohne Angabe von
args
erlauben. - Wenn die Aktion einen Schalter
--help
oder Ähnliches anbietet, verwende diesen als Standard, um eine selbstständige Dokumentation der Aktion herbeizuführen.
jobs.<job_id>.steps[*].with.entrypoint
Überschreibt den Docker-ENTRYPOINT
im Dockerfile
oder legt ihn fest, sofern er noch nicht angegeben wurde. Im Gegensatz zur Docker ENTRYPOINT
-Anweisung, die eine Shell- und eine ausführbare Form aufweist, akzeptiert das Stichwort entrypoint
nur einen einzigen Schritt, der die entsprechende ausführbare Datei definiert.
Beispiel
steps:
- name: Run a custom command
uses: octo-org/action-name@main
with:
entrypoint: /a/different/executable
The entrypoint
keyword is meant to be used with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.
jobs.<job_id>.steps[*].env
Legt Umgebungsvariablen für Schritte fest, die in der Runner-Umgebung verwendet werden sollen. Darüber hinaus kannst Du Umgebungsvariablen für den gesamten Workflow oder für einen Auftrag festlegen. Weitere Informationen findest Du unter env
und jobs.<job_id>.env
.
Wenn mehr als eine Umgebungsvariable mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Umgebungsvariable. Beispielsweise wird eine in einem Schritt definierte Umgebungsvariable die Auftrags- und Workflow-Variablen mit dem gleichen Namen überschreiben, während der Schritt ausgeführt wird. Eine für einen Auftrag definierte Variable überschreibt die Workflow-Variable mit dem gleichen Namen, während der Auftrag ausgeführt wird.
Die erwarteten Umgebungsvariablen können durch öffentliche Aktionen in der README-Datei angegeben werden. Wenn Du ein Geheimnis in einer Umgebungsvariable festlegst, musst Du dieses Geheimnis mit dem Kontext secrets
angeben. For more information, see "Using environment variables" and "Contexts."
Beispiel
steps:
- name: My first action
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
FIRST_NAME: Mona
LAST_NAME: Octocat
jobs.<job_id>.steps[*].continue-on-error
Verhindert das Fehlschlagen eines Auftrags, wenn ein Schritt fehlschlägt. Leg true
fest, damit ein Auftrag auch dann erfolgreich abgeschlossen werden kann, wenn dieser Schritt fehlschlägt.
jobs.<job_id>.steps[*].timeout-minutes
Maximaler Zeitraum in Minuten für die Ausführung des Schritts, bevor der Prozess abgebrochen wird.
jobs.<job_id>.timeout-minutes
Die maximale Anzahl von Minuten, die ein Job ausgeführt wird, bevor GitHub automatisch abbricht. Standard: 360
If the timeout exceeds the job execution time limit for the runner, the job will be canceled when the execution time limit is met instead. For more information about job execution time limits, see "Usage limits, billing, and administration."
jobs.<job_id>.strategy
Mit einer Strategie wird eine Build-Matrix für die Aufträge erstellt. You can define different variations to run each job in.
jobs.<job_id>.strategy.matrix
Du kannst eine Matrix aus verschiedenen Job-Konfigurationen definieren. Mit einer Matrix kannst Du mehrere Jobs erstellen, indem Du in einer einzigen Jobdefinition Variablen substituierst. Zum Beispiel kannst Du eine Matrix verwenden, um Jobs für mehrere unterstützte Versionen einer Programmiersprache, eines Betriebssystems oder eines Tools zu erstellen. Eine Matrix verwendet die Job-Konfiguration mehrfach und erstellt einen Job für jeden Eintrag in der Matrix, die Du konfigurierst.
Eine Auftragsmatrix kann maximal 256 Aufträge pro Workflow-Ausführung generieren. Dieses Limit gilt auch für selbst-gehostete Läufer.
Jede Option, die Du in der Matrix
definierst, hat einen Schlüssel und einen Wert. Die Schlüssel, die Du definierst, werden zu Eigenschaften im Kontext Matrix
und Du kannst diese Eigenschaften in anderen Bereichen Ihrer Workflow-Datei referenzieren. Wenn Du zum Beispiel den Schlüssel os
definierst, der ein Array von Betriebssystemen enthält, kannst Du die Eigenschaft matrix.os
als Wert für das Schlüsselwort runs-on
verwenden, um einen Job für jedes Betriebssystem zu erstellen. Weitere Informationen finden Sie unter „Kontexte“.
Die Reihenfolge, in der Du eine Matrix
definierst, ist wichtig. Die erste Option, die Du definierst, ist der erste Job, der im Workflow ausgeführt wird.
Example: Running multiple versions of Node.js
Zum Erstellen einer Matrix gibst Du ein Array für die Konfigurationsoptionen an. Wenn der Runner beispielsweise die Node.js-Versionen 10, 12 und 14 unterstützt, kannst Du ein Array dieser Versionen in der matrix
festlegen.
Dieses Beispiel erzeugt eine Matrix von drei Jobs, indem der Schlüssel node
auf ein Array von drei Node.js-Versionen gesetzt wird. Um die Matrix zu verwenden, setzt das Beispiel die Kontexteigenschaft matrix.node
als Wert des Eingabeparameters node-version
der Aktion setup-node
. Daher werden drei Jobs ausgeführt, die jeweils eine andere Version von Node.js verwenden.
strategy:
matrix:
node: [10, 12, 14]
steps:
# Configures the node version used on GitHub-hosted runners
- uses: actions/setup-node@v2
with:
# The Node.js version to configure
node-version: ${{ matrix.node }}
Die Aktion setup-node
ist das empfohlene Mittel zur Konfiguration einer Node.js-Version, wenn GitHub-gehostete Runner verwendet werden. Weitere Informationen findest Du in der Aktion setup-node
.
Example: Running with multiple operating systems
Du kannst eine Matrix erstellen, um Workflows auf mehreren Runner-Betriebssystemen auszuführen. Du kannst auch mehrere Matrix-Konfigurationen angeben. Dieses Beispiel erstellt eine Matrix von 6 Jobs:
- 2 Betriebssysteme im Array
os
angegeben - 3 Node.js Versionen im Array
node
angegeben
Wenn Du eine Matrix von Betriebssystemen definierst, musst Du den Wert runs-on
(läuft auf) auf die von Dir definierte Kontexteigenschaft matrix.os
setzen.
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
node: [10, 12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
To find supported configuration options for GitHub-hosted runners, see "Virtual environments for GitHub-hosted runners."
Example: Including additional values into combinations
Zu einem bereits vorhandenen Job mit Buildmatrix kannst Du weitere Konfigurationsoptionen hinzufügen. Wenn Du beispielsweise eine bestimmte Version von npm
verwenden willst, wenn der Auftrag mit windows-latest
und Version 8 von node
ausgeführt wird, kannst Du include
verwenden, um diese zusätzliche Option anzugeben.
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
include:
# includes a new variable of npm with a value of 6
# for the matrix leg matching the os and version
- os: windows-latest
node: 8
npm: 6
Example: Including new combinations
Du kannst include
verwenden, um neue Jobs zu einer Build-Matrix hinzuzufügen. Alle Include-Konfigurationen, die nicht passen, werden zur Matrix hinzugefügt. Wenn Du beispielsweise node
Version 14 verwenden willst, um auf mehreren Betriebssystemen zu bauen, aber Du willst einen zusätzlichen experimentellen Job mit Node Version 15 auf Ubuntu, kannst Du include
verwenden, um diesen zusätzlichen Job anzugeben.
runs-on: ${{ matrix.os }}
strategy:
matrix:
node: [14]
os: [macos-latest, windows-latest, ubuntu-18.04]
include:
- node: 15
os: ubuntu-18.04
experimental: true
Example: Excluding configurations from a matrix
Mit der Option exclude
kannst Du bestimmte in der Build-Matrix definierte Konfigurationen entfernen. Durch die Verwendung von exclude
wird ein durch die Build-Matrix definierter Job entfernt. Die Anzahl der Jobs ist das Kreuzprodukt der Anzahl der Betriebssysteme (os
), die in den von Dir bereitgestellten Arrays enthalten sind, abzüglich etwaiger Subtraktionen (exclude
).
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
exclude:
# excludes node 8 on macOS
- os: macos-latest
node: 8
Hinweis: Alle Kombinationen von include
werden nach exclude
verarbeitet. So kannst Du zuvor ausgeschlossene Kombinationen mit include
wieder hinzufügen.
Using environment variables in a matrix
You can add custom environment variables for each test combination by using the include
key. You can then refer to the custom environment variables in a later step.
In this example, the matrix entries for node-version
are each configured to use different values for the site
and datacenter
environment variables. The Echo site details
step then uses env: ${{ matrix.env }}
to refer to the custom variables:
name: Node.js CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- node-version: 10.x
site: "prod"
datacenter: "site-a"
- node-version: 12.x
site: "dev"
datacenter: "site-b"
steps:
- name: Echo site details
env:
SITE: ${{ matrix.site }}
DATACENTER: ${{ matrix.datacenter }}
run: echo $SITE $DATACENTER
jobs.<job_id>.strategy.fail-fast
Wenn diese Option auf true
gesetzt ist, bricht GitHub alle laufenden Aufträge ab, sobald ein matrix
-Auftrag fehlschlägt. Standard: true
jobs.<job_id>.strategy.max-parallel
Maximale Anzahl der Aufträge, die gleichzeitig ausgeführt werden können, wenn eine matrix
-Jobstrategie verfolgt wird. Standardmäßig führt GitHub so viele Aufträge wie möglich parallel aus, je nach der Anzahl der verfügbaren Runner auf von GitHub gehosteten virtuellen Maschinen.
strategy:
max-parallel: 2
jobs.<job_id>.continue-on-error
Verhindert, dass ein Workflow scheitert, wenn ein Job scheitert. Setze es auf true
um einen Workflow-Lauf fortzusetzen, wenn dieser Job scheitert.
Example: Preventing a specific failing matrix job from failing a workflow run
Du kannst zulassen, dass bestimmte Jobs in einer Jobmatrix scheitert, ohne dass der Workflow-Lauf scheitert. Das gilt beispielsweise, wenn Du nur einem experimentellen Job, bei dem node
auf 15
gesetzt wurde, das Scheitern erlauben willst, ohne dass dadurch der Workflow-Lauf scheitert.
runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
node: [13, 14]
os: [macos-latest, ubuntu-18.04]
experimental: [false]
include:
- node: 15
os: ubuntu-18.04
experimental: true
jobs.<job_id>.container
Ein Container, in dem alle Schritte eines Jobs ausgeführt werden, für die kein Container explizit angegeben ist. Wenn ein Schritt sowohl Skript- als auch Container-Aktionen umfasst, werden die Container-Aktionen als nebengeordnete Container in demselben Netzwerk mit denselben Volume-Mounts ausgeführt.
Wenn Du keinen container
festlegst, werden alle Schritte direkt auf dem Host ausgeführt, der mit runs-on
angegeben ist, außer wenn ein Schritt auf eine Aktion verweist, die für die Ausführung in einem Container konfiguriert ist.
Beispiel
jobs:
my_job:
container:
image: node:14.16
env:
NODE_ENV: development
ports:
- 80
volumes:
- my_docker_volume:/volume_mount
options: --cpus 1
Wenn Du nur ein Container-Image angibst, kannst Du das Stichwort image
weglassen.
jobs:
my_job:
container: node:14.16
jobs.<job_id>.container.image
Docker-Image, das beim Ausführen der Aktion als Container herangezogen wird. The value can be the Docker Hub image name or a public registry name.
jobs.<job_id>.container.env
Legt eine map
mit Umgebungsvariablen im Container fest.
jobs.<job_id>.container.ports
Legt ein array
mit Ports fest, die im Container offengelegt werden.
jobs.<job_id>.container.volumes
Legt ein array
mit Volumes für den Container fest. Mithilfe von Volumes kannst Du Daten zwischen Diensten oder anderen Schritten in einem Job austauschen. Du kannst benannte Docker-Volumes, anonyme Docker-Volumes oder Bind-Mounts auf dem Host angegeben.
Um ein Volume festzulegen, gibst Du den Quell- und Zielpfad an:
<source>:<destinationPath>
.
<source>
bezeichnet einen Volume-Namen oder einen absoluten Pfad auf der Hostmaschine und <destinationPath>
einen absoluten Pfad im Container.
Beispiel
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.container.options
Zusätzliche Optionen für die Docker-Container-Ressource. Eine Liste der Optionen findest Du unter „Optionen für docker create
“.
Warning: The --network
option is not supported.
jobs.<job_id>.services
Hinweis: Wenn Deine Workflows Docker-Containeraktionen oder Dienstcontainer verwenden, musst Du einen Linux-Läufer verwenden:
- If you are using GitHub-hosted runners, you must use an Ubuntu runner.
- Wenn Du selbst gehostete Läufer verwendest, musst Du einen Linux-Rechner als Deinen Läufer verwenden und Docker muss installiert sein.
Wird zum Betrieb von Servicecontainern für einen Job in einem Workflow verwendet. Servicecontainer sind nützlich, um Datenbanken oder Cache-Dienste wie Redis zu erstellen. Der Runner erstellt automatisch ein Docker-Netzwerk und verwaltet den Lebenszyklus der Service-Container.
Wenn Du Deinen Job so konfigurieren, dass er in einem Container läuft, oder wenn Dein Schritt Containeraktionen verwendet, brauchst Du keine Ports zuordnen, um auf den Dienst oder die Aktion zuzugreifen. Docker öffnet automatisch alle Ports zwischen Containern im selben benutzerdefinierten Bridge-Netzwerk des Dockers. Du kannst den Servicecontainer direkt mit seinem Hostnamen referenzieren. Der Hostname wird automatisch dem Namen des Labels zugeordnet, den Du für den Dienst im Workflow konfigurierst.
Wenn Du den Job so konfigurierst, dass er direkt auf der Runner-Maschine läuft und Dein Schritt keine Container-Aktion verwendet, musst Du alle erforderlichen Ports des Docker-Servicecontainers dem Docker-Host (der Runner-Maschine) zuordnen. Du kannst auf den Servicecontainer über localhost und den zugeordneten Port zugreifen.
Weitere Informationen über die Unterschiede zwischen Netzwerk-Servicecontainern finden Sie unter „Informationen zu Servicecontainern“.
Example: Using localhost
Dieses Beispiel erzeugt zwei Dienste: nginx und redis. Wenn Du den Port des Docker-Hosts angibst, aber nicht den des Containers, dann wird der Container-Port zufällig einem freien Port zugewiesen. GitHub setzt den zugewiesenen Containerport im Kontext ${{job.services.<service_name>.ports}}
. In diesem Beispiel kannst Du über die Kontexte ${{ job.services.nginx.ports['8080'] }}
und ${{ job.services.redis.ports['6379'] }}
auf die Ports des Servicecontainers zugreifen.
services:
nginx:
image: nginx
# Port 8080 des Docker-Hosts dem Port 80 des nginx-Containers zuordnen
ports:
- 8080:80
redis:
image: redis
# TCP-Port 6379 des Docker-Hosts einem freien Port des Redis-Containers zufällig zuordnen
ports:
- 6379/tcp
jobs.<job_id>.services.<service_id>.image
Docker-Image, das beim Ausführen der Aktion als Dienstcontainer herangezogen wird. The value can be the Docker Hub image name or a public registry name.
jobs.<job_id>.services.<service_id>.env
Legt eine map
mit Umgebungsvariablen im Servicecontainer fest.
jobs.<job_id>.services.<service_id>.ports
Legt ein array
mit Ports fest, die im Dienstcontainer offengelegt werden.
jobs.<job_id>.services.<service_id>.volumes
Legt ein array
mit Volumes für den Dienstcontainer fest. Mithilfe von Volumes kannst Du Daten zwischen Diensten oder anderen Schritten in einem Job austauschen. Du kannst benannte Docker-Volumes, anonyme Docker-Volumes oder Bind-Mounts auf dem Host angegeben.
Um ein Volume festzulegen, gibst Du den Quell- und Zielpfad an:
<source>:<destinationPath>
.
<source>
bezeichnet einen Volume-Namen oder einen absoluten Pfad auf der Hostmaschine und <destinationPath>
einen absoluten Pfad im Container.
Beispiel
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.services.<service_id>.options
Zusätzliche Optionen für die Docker-Container-Ressource. Eine Liste der Optionen findest Du unter „Optionen für docker create
“.
Warning: The --network
option is not supported.
Spickzettel zu Filtermustern
In Pfad-, Branch- und Tag-Filtern kannst Du Sonderzeichen benutzen.
*
Steht für kein Zeichen oder mehrere Zeichen, nicht jedoch für den Schrägstrich (/
). Zum Beispiel passtOkto*
aufOktocat
.**
: Steht für kein Zeichen oder mehrere beliebige Zeichen.?
: Matches zero or one of the preceding character.+
: Matches one or more of the preceding character.[]
Steht für irgend ein Zeichen, das in den Klammern aufgelistet ist oder das in einen in den Klammern enthalten Bereich fällt. Mögliche Bereiche sind ausschließlicha-z
,A-Z
und0-9
. For example, the range[0-9a-z]
matches any digit or lowercase letter. Zum Beispiel passt[CB]at
sowohl zuCat
als auch zuBat
und[1-2]00
passt sowohl zu100
als auch zu200
.!
: Am Anfang eines Musters stehend negiert es das Muster in sein Gegenteil. Es hat keine besondere Bedeutung, wenn es nicht das erste Zeichen ist.
Die Zeichen *
, [
und !
sind Sonderzeichen in YAML. Wenn ein Muster mit *
, [
oder !
beginnen soll, schließe das Muster in Anführungszeichen ein.
# Gueltig
- '**/README.md'
# Ungueltig - verursacht einen Parserfehler,
# der verhindert, dass der Workflow laeuft.
- **/README.md
Weitere Informationen zur Syntax für Branch-, Tag- und Pfadfilter findest Du unter „on.<push|pull_request>.<branches|tags>
“ und „on.<push|pull_request>.paths
“.
Muster für den Abgleich von Branches und Tags
Muster | Beschreibung | Beispiele für Übereinstimmungen |
---|---|---|
feature/* | Das Platzhalterzeichen * steht für ein beliebiges Zeichen, nicht jedoch für den Schrägstrich (/ ). | feature/my-branch feature/your-branch |
feature/** | Das Platzhalterzeichen ** steht für ein beliebiges Zeichen, also auch für den Schrägstrich (/ ), in Branch- und Tag-Namen. | feature/beta-a/my-branch feature/your-branch feature/mona/the/octocat |
main releases/mona-the-octocat | Abgleich mit dem exakten Branch- oder Tag-Namen. | main releases/mona-the-octocat |
'*' | Abgleich mit allen Branch- und Tag-Namen, die keinen Schrägstrich (/ ) enthalten. Das Zeichen * ist ein Sonderzeichen in YAML. Wenn ein Muster mit * beginnen soll, sind Anführungszeichen erforderlich. | main releases |
'**' | Abgleich mit allen Branch- und Tag-Namen. Dies ist das Standardverhalten, wenn Sie keinen branches - oder tags -Filter angeben. | all/the/branches every/tag |
'*feature' | Das Zeichen * ist ein Sonderzeichen in YAML. Wenn ein Muster mit * beginnen soll, sind Anführungszeichen erforderlich. | mona-feature feature ver-10-feature |
v2* | Abgleich mit Branch- und Tag-Namen, die mit v2 beginnen. | v2 v2.0 v2.9 |
v[12].[0-9]+.[0-9]+ | Matches all semantic versioning branches and tags with major version 1 or 2 | v1.10.1 v2.0.0 |
Muster für den Abgleich von Dateinamen
Pfadmuster müssen mit dem gesamten Pfad übereinstimmen und mit dem Root des Repositorys beginnen.
Muster | Beschreibung der Übereinstimmungen | Beispiele für Übereinstimmungen |
---|---|---|
'*' | Das Platzhalterzeichen * steht für ein beliebiges Zeichen, nicht jedoch für den Schrägstrich (/ ). Das Zeichen * ist ein Sonderzeichen in YAML. Wenn ein Muster mit * beginnen soll, sind Anführungszeichen erforderlich. | README.md server.rb |
'*.jsx?' | Das Zeichen ? steht für null Instanzen oder genau eine Instanz des vorangegangenen Zeichens. | page.js page.jsx |
'**' | Das Platzhalterzeichen ** steht für ein beliebiges Zeichen, auch für den Schrägstrich (/ ). Dies ist das Standardverhalten, wenn Sie keinen path -Filter angeben. | all/the/files.md |
'*.js' | Das Platzhalterzeichen * steht für ein beliebiges Zeichen, nicht jedoch für den Schrägstrich (/ ). Abgleich mit allen .js -Dateien im Root des Repositorys. | app.js index.js |
'**.js' | Abgleich mit allen .js -Dateien im Repository. | index.js js/index.js src/js/app.js |
docs/* | Alle Dateien im Root des Verzeichnisses docs im Root des Repositorys. | docs/README.md docs/file.txt |
docs/** | Beliebige Dateien im Verzeichnis docs im Root des Repositorys. | docs/README.md docs/mona/octocat.txt |
docs/**/*.md | Eine Datei mit dem Suffix .md an beliebiger Stelle im Verzeichnis docs . | docs/README.md docs/mona/hello-world.md docs/a/markdown/file.md |
'**/docs/**' | Beliebige Dateien im Verzeichnis docs an beliebiger Stelle im Repository. | docs/hello.md dir/docs/my-file.txt space/docs/plan/space.doc |
'**/README.md' | Eine Datei mit dem Namen „README.md“ an beliebiger Stelle im Repository. | README.md js/README.md |
'**/*src/**' | Eine beliebige Datei in einem Ordner mit dem Suffix src an beliebiger Stelle im Repository. | a/src/app.js my-src/code/js/app.js |
'**/*-post.md' | Eine Datei mit dem Suffix -post.md an beliebiger Stelle im Repository. | my-post.md path/their-post.md |
'**/migrate-*.sql' | Eine Datei mit dem Präfix migrate- und dem Suffix .sql an beliebiger Stelle im Repository. | migrate-10909.sql db/migrate-v1.0.sql db/sept/migrate-v1.sql |
*.md !README.md | Ein Ausrufezeichen (! ) vor einem Muster negiert das Muster. Wenn eine Datei sowohl mit einem Muster übereinstimmt als auch mit einem negativen Muster, das später in der Datei definiert ist, wird die Datei nicht berücksichtigt. | hello.md Does not match README.md docs/hello.md |
*.md !README.md README* | Die Muster werden sequenziell geprüft. Wenn ein Muster ein vorangegangenes Muster negiert, werden die Dateipfade wieder berücksichtigt. | hello.md README.md README.doc |