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 Kontexten
Kontexte sind eine Möglichkeit, auf Informationen zu Workflowausführungen, Variablen, Runnerumgebungen, Aufträge und Schritten zuzugreifen. Ein Kontext ist ein Objekt, das Eigenschaften enthält. Dabei kann es sich um Zeichenfolgen oder andere Objekte handeln.
Kontexte, Objekte und Eigenschaften variieren bei verschiedenen Workflowausführungsbedingungen erheblich. Der Kontext matrix
wird beispielsweise nur für Aufträge in einer Matrix aufgefüllt.
Mithilfe der Syntax für Ausdrücke können Sie auf Kontexte zugreifen. Weitere Informationen finden Sie unter Auswerten von Ausdrücken in Workflows und Aktionen.
${{ <context> }}
Warnung: Beim Erstellen von Workflows und Aktionen solltest du immer überprüfen, ob dein Code gegebenenfalls nicht vertrauenswürdige Eingaben von Angreifern ausführen kann. Bestimmte Kontexte sollten als nicht vertrauenswürdige Eingaben behandelt werden, da ein Angreifer seine eigenen schädlichen Inhalte einfügen könnte. Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.
Kontextname | type | BESCHREIBUNG |
---|---|---|
github | object | Informationen zum Workflow-Lauf. Weitere Informationen finden Sie unter Kontext github . |
env | object | Enthält Variablen, die in einem Workflow, Auftrag oder Schritt festgelegt sind. Weitere Informationen finden Sie unter Kontext env . |
vars | object | Enthält benutzerdefinierte Konfigurationsvariablen, die auf Repository-, Organisations- und Umgebungsebene festgelegt sind. Weitere Informationen findest du unter Kontext vars . |
job | object | Informationen zum derzeit ausgeführten Auftrag. Weitere Informationen findest du unter Kontext job . |
jobs | object | Nur für wiederverwendbare Workflows. Enthält Ausgaben von Aufträgen aus dem wiederverwendbaren Workflow. Weitere Informationen finden Sie unter Kontext jobs . |
steps | object | Informationen zu den Schritten, die im aktuellen Auftrag ausgeführt werden. Weitere Informationen finden Sie unter Kontext steps . |
runner | object | Informationen zum Runner, der den aktuellen Auftrag ausführt. Weitere Informationen finden Sie unter Kontext runner . |
secrets | object | Enthält die Namen und Werte von Geheimnissen, die für eine Workflowausführung verfügbar sind. Weitere Informationen finden Sie unter Kontext secrets . |
strategy | object | Informationen zur Ausführungsstrategie der Matrix für den aktuellen Auftrag. Weitere Informationen finden Sie unter Kontext strategy . |
matrix | object | Enthält die im Workflow definierten Matrixeigenschaften, die für den aktuellen Auftrag gelten. Weitere Informationen finden Sie unter Kontext matrix . |
needs | object | Enthält die Ausgaben aller Aufträge, die als Abhängigkeit des aktuellen Auftrags definiert sind. Weitere Informationen finden Sie unter Kontext needs . |
inputs | object | Enthält die Eingaben eines wiederverwendbaren oder manuell ausgelösten Workflows. Weitere Informationen finden Sie unter Kontext inputs . |
Als Teil eines Ausdrucks können Sie mit einer der beiden folgenden Syntaxarten auf Kontextinformationen zugreifen.
- Indexsyntax:
github['sha']
- Syntax zur Dereferenzierung von Eigenschaften:
github.sha
Um die Syntax zur Dereferenzierung von Eigenschaften zu verwenden, muss der Eigenschaftsname mit einem Buchstaben oder _
beginnen oder nur alphanumerische Zeichen, -
oder _
enthalten.
Wenn Sie versuchen, eine nicht vorhandene Eigenschaft zu dereferenzieren, wird sie als leere Zeichenfolge ausgewertet.
Anwendungsfälle für Kontexte
GitHub Actions enthält eine Sammlung von Variablen namens Kontexte und eine ähnliche Sammlung von Variablen namens Standardvariablen. Umgebungsvariablen und Kontexte sind für verschiedene Stellen im Workflow vorgesehen:
- Standardumgebungsvariablen: Diese Umgebungsvariablen sind nur auf dem Runner vorhanden, der deinen Auftrag ausführt. Weitere Informationen findest du unter Speichern von Informationen in Variablen.
- Kontexte: Du kannst die meisten Kontexte an einem beliebigen Punkt in deinem Workflow verwenden, einschließlich wenn Standardvariablen nicht verfügbar sind. Du kannst beispielsweise Kontexte mit Ausdrücken verwenden, um die anfängliche Verarbeitung auszuführen, bevor der Auftrag zur Ausführung an einen Runner weitergeleitet wird; dadurch kannst du einen Kontext mit dem bedingten
if
-Schlüsselwort verwenden, um festzustellen, ob ein Schritt ausgeführt werden soll. Sobald der Auftrag ausgeführt wird, kannst du auch Kontextvariablen aus dem Runner abrufen, der den Auftrag ausführt, so wierunner.os
. Ausführliche Informationen dazu, wo du bestimmte Kontexte innerhalb eines Workflows verwenden kannst, findest du unter „Kontextverfügbarkeit“.
Im folgenden Beispiel wird veranschaulicht, wie diese verschiedenen Variablentypen in einem Auftrag zusammen verwendet werden können:
name: CI on: push jobs: prod-check: if: ${{ github.ref == 'refs/heads/main' }} runs-on: ubuntu-latest steps: - run: echo "Deploying to production server on branch $GITHUB_REF"
name: CI
on: push
jobs:
prod-check:
if: ${{ github.ref == 'refs/heads/main' }}
runs-on: ubuntu-latest
steps:
- run: echo "Deploying to production server on branch $GITHUB_REF"
In diesem Beispiel überprüft die if
-Anweisung den Kontext, um den github.ref
aktuellen Zweignamen zu ermitteln; wenn der Name refs/heads/main
lautet, werden die nachfolgenden Schritte ausgeführt. Die if
-Überprüfung wird von GitHub Actions verarbeitet und der Auftrag wird nur an den Runner gesendet, wenn das Ergebnis true
ist. Sobald der Auftrag an den Runner gesendet wird, wird der Schritt ausgeführt und verweist auf die $GITHUB_REF
-Variable des Runners.
Kontextverfügbarkeit
Bei der Ausführung eines Workflows stehen verschiedene Kontexte zur Verfügung. Der secrets
-Kontext kann beispielsweise nur an bestimmten Stellen innerhalb eines Auftrags verwendet werden.
Darüber hinaus können auch einige Funktionen nur an bestimmten Stellen verwendet werden. Die Funktion hashFiles
ist beispielsweise nicht überall verfügbar.
In der folgenden Tabelle siehst du, an welchen Stellen die einzelnen Kontexte und Sonderfunktionen innerhalb eines Workflows verwendet werden können. Funktionen, die nicht in der Liste aufgeführt werden, können überall verwendet werden.
Workflowschlüssel | Kontext | Sonderfunktionen |
---|---|---|
run-name | github, inputs, vars | Keine |
concurrency | github, inputs, vars | Nein |
env | github, secrets, inputs, vars | Nein |
jobs.<job_id>.concurrency | github, needs, strategy, matrix, inputs, vars | Nein |
jobs.<job_id>.container | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.container.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | Nein |
jobs.<job_id>.container.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | Nein |
jobs.<job_id>.container.image | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.continue-on-error | github, needs, strategy, vars, matrix, inputs | Nein |
jobs.<job_id>.defaults.run | github, needs, strategy, matrix, env, vars, inputs | Nein |
jobs.<job_id>.env | github, needs, strategy, matrix, vars, secrets, inputs | Nein |
jobs.<job_id>.environment | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.environment.url | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | Nein |
jobs.<job_id>.if | github, needs, vars, inputs | always, cancelled, success, failure |
jobs.<job_id>.name | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.outputs.<output_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | Nein |
jobs.<job_id>.runs-on | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.secrets.<secrets_id> | github, needs, strategy, matrix, secrets, inputs, vars | Nein |
jobs.<job_id>.services | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.services.<service_id>.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | Nein |
jobs.<job_id>.services.<service_id>.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | Nein |
jobs.<job_id>.steps.continue-on-error | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.env | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | always, cancelled, success, failure, hashFiles |
jobs.<job_id>.steps.name | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.run | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.timeout-minutes | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.with | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.working-directory | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.strategy | github, needs, vars, inputs | Nein |
jobs.<job_id>.timeout-minutes | github, needs, strategy, matrix, vars, inputs | Nein |
jobs.<job_id>.with.<with_id> | github, needs, strategy, matrix, inputs, vars | Nein |
on.workflow_call.inputs.<inputs_id>.default | github, inputs, vars | Nein |
on.workflow_call.outputs.<output_id>.value | github, jobs, vars, inputs | Keine |
Beispiel: Drucken von Kontextinformationen ins Protokoll
Sie können den Inhalt von Kontexten zum Debuggen ins Protokoll drucken. Die Funktion toJSON
ist für die Quelltextformatierung von JSON-Objekten im Protokoll erforderlich
Warnung: Achte bei der Verwendung des gesamten github
-Kontexts darauf, dass darin vertrauliche Informationen wie github.token
enthalten sind. GitHub maskiert Geheimnisse, wenn sie auf die Konsole ausgegeben werden, aber du solltest beim Exportieren oder Drucken des Kontexts vorsichtig sein.
name: Context testing on: push jobs: dump_contexts_to_log: runs-on: ubuntu-latest steps: - name: Dump GitHub context env: GITHUB_CONTEXT: ${{ toJson(github) }} run: echo "$GITHUB_CONTEXT" - name: Dump job context env: JOB_CONTEXT: ${{ toJson(job) }} run: echo "$JOB_CONTEXT" - name: Dump steps context env: STEPS_CONTEXT: ${{ toJson(steps) }} run: echo "$STEPS_CONTEXT" - name: Dump runner context env: RUNNER_CONTEXT: ${{ toJson(runner) }} run: echo "$RUNNER_CONTEXT" - name: Dump strategy context env: STRATEGY_CONTEXT: ${{ toJson(strategy) }} run: echo "$STRATEGY_CONTEXT" - name: Dump matrix context env: MATRIX_CONTEXT: ${{ toJson(matrix) }} run: echo "$MATRIX_CONTEXT"
name: Context testing
on: push
jobs:
dump_contexts_to_log:
runs-on: ubuntu-latest
steps:
- name: Dump GitHub context
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
- name: Dump job context
env:
JOB_CONTEXT: ${{ toJson(job) }}
run: echo "$JOB_CONTEXT"
- name: Dump steps context
env:
STEPS_CONTEXT: ${{ toJson(steps) }}
run: echo "$STEPS_CONTEXT"
- name: Dump runner context
env:
RUNNER_CONTEXT: ${{ toJson(runner) }}
run: echo "$RUNNER_CONTEXT"
- name: Dump strategy context
env:
STRATEGY_CONTEXT: ${{ toJson(strategy) }}
run: echo "$STRATEGY_CONTEXT"
- name: Dump matrix context
env:
MATRIX_CONTEXT: ${{ toJson(matrix) }}
run: echo "$MATRIX_CONTEXT"
Kontext github
Der github
-Kontext enthält Informationen zur Workflowausführung und zum Ereignis, das die Ausführung ausgelöst hat. Die meisten Daten zum github
-Kontext können Sie auch in Umgebungsvariablen lesen. Weitere Informationen zu Umgebungsvariablen finden Sie unter Speichern von Informationen in Variablen.
Warnung: Achte bei der Verwendung des gesamten github
-Kontexts darauf, dass darin vertrauliche Informationen wie github.token
enthalten sind. GitHub maskiert Geheimnisse, wenn sie auf die Konsole ausgegeben werden, aber du solltest beim Exportieren oder Drucken des Kontexts vorsichtig sein.
Warnung: Beim Erstellen von Workflows und Aktionen solltest du immer überprüfen, ob dein Code gegebenenfalls nicht vertrauenswürdige Eingaben von Angreifern ausführen kann. Bestimmte Kontexte sollten als nicht vertrauenswürdige Eingaben behandelt werden, da ein Angreifer seine eigenen schädlichen Inhalte einfügen könnte. Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
github | object | Der Top-Level-Kontext, der bei jedem Job oder Schritt im Workflow verfügbar ist. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
github.action | string | Name der aktuell ausgeführten Aktion oder der id -Wert eines Schritts. GitHub entfernt Sonderzeichen und verwendet den Namen __run , wenn der aktuelle Schritt ein Skript ohne id ausführt. Wenn du eine Aktion mehr als einmal im selben Auftrag verwendest, enthält der Name ein Suffix mit der Sequenznummer, der ein Unterstrich vorangestellt wird. So lautet z. B. der Name des ersten Skripts, das du ausführst, __run und der des zweiten __run_2 . Analog dazu erhält der zweite Aufruf von actions/checkout den Namen actionscheckout2 . |
github.action_path | string | Pfad einer Aktion. Diese Eigenschaft wird nur in zusammengesetzten Aktionen unterstützt. Sie können diesen Pfad verwenden, um auf Dateien zuzugreifen, die sich im selben Repository wie die Aktion befinden, z. B. indem du Verzeichnisse in den Pfad änderst: cd ${{ github.action_path }} . |
github.action_ref | string | Bei einem Schritt, in dem eine Aktion ausgeführt wird, verweist diese Eigenschaft auf die ausgeführte Aktion. Beispiel: v2 .Nicht verwenden im run Schlüsselwort. Um diesen Kontext mit zusammengesetzten Aktionen zu verwenden, verweisen Sie im env -Kontext der zusammengesetzten Aktion darauf. |
github.action_repository | string | Bei einem Schritt, in dem eine Aktion ausgeführt wird, gibt diese Eigenschaft den Namen des Besitzers bzw. der Besitzerin und des Repositorys der Aktion an. Beispiel: actions/checkout .Nicht verwenden im run Schlüsselwort. Um diesen Kontext mit zusammengesetzten Aktionen zu verwenden, verweisen Sie im env -Kontext der zusammengesetzten Aktion darauf. |
github.action_status | string | Das aktuelle Ergebnis einer zusammengesetzten Aktion. |
github.actor | string | Benutzername des Benutzers bzw. der Benutzerin, der/die die erste Workflowausführung ausgelöst hat. Wenn die Workflowausführung eine erneute Ausführung ist, unterscheidet sich dieser Wert möglicherweise von github.triggering_actor . Alle Workflowneuausführungen verwenden die Berechtigungen von github.actor , auch wenn der Akteur bzw. die Akteurin, der/die die Neuausführung (github.triggering_actor ) initiiert, unterschiedliche Berechtigungen hat. |
github.actor_id | string | Die Konto-ID der Person oder App, die die ursprüngliche Workflowausführung ausgelöst hat. Beispiel: 1234567 . Beachte, dass sie sich vom Benutzernamen des Akteurs unterscheidet. |
github.api_url | string | URL der GitHub-REST-API. |
github.base_ref | string | base_ref - oder Zielbranch des Pull Requests in einer Workflowausführung. Diese Eigenschaft ist nur verfügbar, wenn es sich bei dem Ereignis, das eine Workflowausführung auslöst, um pull_request oder pull_request_target handelt. |
github.env | string | Pfad des Runners zur Datei, die Umgebungsvariablen aus Workflowbefehlen festlegt. Diese Datei ist für den aktuellen Schritt eindeutig und unterscheidet sich für jeden Schritt in einem Auftrag. Weitere Informationen findest du unter Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions). |
github.event | object | Die vollständige Nutzlast des Ereignis-Webhooks. Mit diesem Kontext kannst du auf einzelne Eigenschaften des Ereignisses zugreifen. Dieses Objekt ist identisch mit der Webhooknutzlast des Ereignisses, das die Workflowausführung ausgelöst hat, und unterscheidet sich für jedes Ereignis. Die Webhooks für jedes GitHub Actions-Ereignis werden unter Ereignisse zum Auslösen von Workflows verknüpft. Für einen Workflow, der vom Ereignis push ausgelöst wird, enthält dieses Objekt beispielsweise den Inhalt der Webhooknutzlast „push“. |
github.event_name | string | Der Name des Ereignisses, das den Workflow-Lauf ausgelöst hat. |
github.event_path | string | Pfad des Runners zur Datei mit der vollständigen Webhooknutzlast des Ereignisses. |
github.graphql_url | string | URL der GitHub-GraphQL-API. |
github.head_ref | string | head_ref - oder Quellbranch des Pull Requests in einer Workflowausführung. Diese Eigenschaft ist nur verfügbar, wenn es sich bei dem Ereignis, das eine Workflowausführung auslöst, um pull_request oder pull_request_target handelt. |
github.job | string | job_id -Wert des aktuellen Auftrags. Hinweis: Diese Kontexteigenschaft wird vom Actions-Runner festgelegt und ist nur innerhalb der steps der Ausführung eines Auftrags verfügbar. Andernfalls ist der Wert dieser Eigenschaft null . |
github.path | string | Pfad auf dem Runner zu der Datei, in der die PATH -Systemvariablen aus Workflowbefehlen festgelegt sind. Diese Datei ist für den aktuellen Schritt eindeutig und unterscheidet sich für jeden Schritt in einem Auftrag. Weitere Informationen findest du unter Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions). |
github.ref | string | Das vollständig geformte Ref des Branch- oder Tagnamens, der die Workflowausführung ausgelöst hat. Bei Workflows, die durch push ausgelöst wurden, ist dies das Branch- oder Tag-Ref, das gepusht wurde. Bei Workflows, die von pull_request ausgelöst werden, ist dies der Branch für das Mergen des Pull Requests. Bei Workflows, die von release ausgelöst werden, ist dies das erstellte Releasetag. Bei anderen Triggern handelt es sich um das Branch- oder Tag-Ref, das die Workflowausführung ausgelöst hat. Es wird nur festgelegt, wenn für den Ereignistyp ein Branch oder ein Tag verfügbar ist. Das Ref ist vollständig gebildet, d.h. für Branches ist das Format refs/heads/<branch_name> , für Pull Requests refs/pull/<pr_number>/merge und für Tags refs/tags/<tag_name> . Beispiel: refs/heads/feature-branch-1 . |
github.ref_name | string | Der kurze Ref-Name des Branches oder Tags, der bzw. das die Workflowausführung ausgelöst hat. Dieser Wert entspricht dem Branch- oder Tagnamen, der auf GitHub angezeigt wird. Beispiel: feature-branch-1 .Für Pull Requests ist das Format <pr_number>/merge . |
github.ref_protected | boolean | true wenn Verzweigungsschutz für den Verweis konfiguriert sind, der die Workflow-Ausführung ausgelöst hat. |
github.ref_type | string | Der Typ des Verweises, der die Workflowausführung ausgelöst hat. Gültige Werte sind branch und tag . |
github.repository | string | Name des Eigentümers und des Repositorys. Beispiel: octocat/Hello-World . |
github.repository_id | string | Die ID des Repositorys. Beispiel: 123456789 . Beachte, dass sie sich vom Repositorynamen unterscheidet. |
github.repository_owner | string | Benutzername des Repositorybesitzers. Beispiel: octocat . |
github.repository_owner_id | string | Die Konto-ID des Repositorybesitzers bzw. der Repositorybesitzerin. Beispiel: 1234567 . Beachte, dass sie sich vom Besitzernamen unterscheidet. |
github.repositoryUrl | string | Git-URL zum Repository. Beispiel: git://github.com/octocat/hello-world.git . |
github.retention_days | string | Anzahl der Tage, für die Protokolle und Artefakte der Workflowausführung beibehalten werden. |
github.run_id | string | Eine eindeutige Zahl für jeden Workflow, der innerhalb eines Repositorys ausgeführt wird. Diese Nummer ändert sich nicht, wenn Du den Workflowablauf erneut ausführst. |
github.run_number | string | Eine eindeutige Nummer für jede Ausführung eines bestimmten Workflows in einem Repository. Diese Zahl beginnt bei 1 für die erste Ausführung des Workflows und wird bei jeder neuen Ausführung erhöht. Diese Nummer ändert sich nicht, wenn Du den Workflowablauf erneut ausführst. |
github.run_attempt | string | Eine eindeutige Nummer für jeden Versuch einer bestimmten Workflowausführung in einem Repository. Diese Nummer beginnt bei 1 für den ersten Versuch der Workflowausführung und erhöht sich mit jeder weiteren Ausführung um 1. |
github.secret_source | string | Quelle eines Geheimnisses, das in einem Workflow verwendet wird. Mögliche Werte sind None , Actions oder Dependabot . |
github.server_url | string | URL des GitHub-Servers. Beispiel: https://github.com |
github.sha | string | Der Commit-SHA-Wert, der den Workflow ausgelöst hat. Dieser Wert hängt von dem Ereignis ab, das den Workflow ausgelöst hat. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows. Beispiel: ffac537e6cbbf934b08745a378932722df287a53 . |
github.token | string | Token zur Authentifizierung im Namen der in Ihrem Repository installierten GitHub-App. Diese Funktion entspricht dem Geheimnis GITHUB_TOKEN . Weitere Informationen finden Sie unter Automatische Tokenauthentifizierung. Hinweis: Diese Kontexteigenschaft wird vom Actions-Runner festgelegt und ist nur innerhalb der steps der Ausführung eines Auftrags verfügbar. Andernfalls ist der Wert dieser Eigenschaft null . |
github.triggering_actor | string | Benutzername des Benutzers bzw. der Benutzerin, der bzw. die die Workflowausführung initiiert hat. Wenn die Workflowausführung eine erneute Ausführung ist, unterscheidet sich dieser Wert möglicherweise von github.actor . Alle Workflowneuausführungen verwenden die Berechtigungen von github.actor , auch wenn der Akteur bzw. die Akteurin, der/die die Neuausführung (github.triggering_actor ) initiiert, unterschiedliche Berechtigungen hat. |
github.workflow | string | Der Name des Workflows. Wird in der Workflowdatei kein name -Wert festgelegt, entspricht der Wert dieser Eigenschaft dem vollständigen Pfad der Workflowdatei im Repository. |
github.workflow_ref | string | Der Verweispfad zum Workflow. Beispiel: octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch . |
github.workflow_sha | string | Der Commit-SHA für die Workflowdatei. |
github.workspace | string | Standardarbeitsverzeichnis des Runners für die Schritte und Standardspeicherort deines Repositorys bei Verwendung der Aktion checkout . |
Beispielinhalt des github
-Kontexts
Der folgende Beispielkontext stammt aus einer Workflowausführung, die vom Ereignis push
ausgelöst wurde. Das event
-Objekt in diesem Beispiel wurde gekürzt, da es mit dem Inhalt der Webhooknutzlast push
identisch ist.
Hinweis: Dieser Kontext ist nur ein Beispiel. Der Inhalt eines Kontexts hängt vom ausgeführten Workflow ab. Kontexte, Objekte und Eigenschaften variieren bei verschiedenen Workflowausführungsbedingungen erheblich.
{
"token": "***",
"job": "dump_contexts_to_log",
"ref": "refs/heads/my_branch",
"sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369",
"repository": "octocat/hello-world",
"repository_owner": "octocat",
"repositoryUrl": "git://github.com/octocat/hello-world.git",
"run_id": "1536140711",
"run_number": "314",
"retention_days": "90",
"run_attempt": "1",
"actor": "octocat",
"workflow": "Context testing",
"head_ref": "",
"base_ref": "",
"event_name": "push",
"event": {
...
},
"server_url": "https://github.com",
"api_url": "https://api.github.com",
"graphql_url": "https://api.github.com/graphql",
"ref_name": "my_branch",
"ref_protected": false,
"ref_type": "branch",
"secret_source": "Actions",
"workspace": "/home/runner/work/hello-world/hello-world",
"action": "github_step",
"event_path": "/home/runner/work/_temp/_github_workflow/event.json",
"action_repository": "",
"action_ref": "",
"path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602",
"env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602"
}
Beispielverwendung des github
-Kontexts
In diesem Beispielworkflow wird der github.event_name
-Kontext verwendet, um einen Auftrag nur dann auszuführen, wenn die Workflowausführung vom Ereignis pull_request
ausgelöst wurde.
name: Run CI on: [push, pull_request] jobs: normal_ci: runs-on: ubuntu-latest steps: - name: Run normal CI run: echo "Running normal CI" pull_request_ci: runs-on: ubuntu-latest if: ${{ github.event_name == 'pull_request' }} steps: - name: Run PR CI run: echo "Running PR only CI"
name: Run CI
on: [push, pull_request]
jobs:
normal_ci:
runs-on: ubuntu-latest
steps:
- name: Run normal CI
run: echo "Running normal CI"
pull_request_ci:
runs-on: ubuntu-latest
if: ${{ github.event_name == 'pull_request' }}
steps:
- name: Run PR CI
run: echo "Running PR only CI"
Kontext env
Der env
-Kontext enthält Variablen, die in einem Workflow, Auftrag oder Schritt festgelegt wurden. Er enthält keine Variablen, die vom Runner-Prozess geerbt werden. Weitere Informationen zum Festlegen von Variablen in deinem Workflow finden Sie unter "Workflowsyntax für GitHub Actions."
Sie können die Werte von Variablen abrufen, die im env
-Kontext gespeichert sind, und diese Werte in Ihrer Workflowdatei verwenden. Sie können den env
-Kontext im Wert eines beliebigen Schlüssels in einem Schritt verwenden, mit Ausnahme der Schlüssel id
und uses
. Weitere Informationen zur Schrittsyntax finden Sie unter "Workflowsyntax für GitHub Actions."
Wenn Sie den Wert einer Variablen innerhalb eines Runners verwenden möchten, dann verwenden Sie die übliche Methode des Runner-Betriebssystems zum Lesen von Umgebungsvariablen.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
env | object | Dieser Kontext ändert sich bei jedem Schritt in einem Auftrag. Sie können bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. Dieses Objekt enthält die unten aufgeführten Eigenschaften. |
env.<env_name> | string | Der Wert einer bestimmten Umgebungsvariable. |
Beispielinhalt des env
-Kontexts
Der Inhalt des env
-Kontexts ist eine Zuordnung der Variablennamen zu ihren Werten. Je nach der Stelle in der Workflowausführung kann der Inhalt des Kontexts variieren. In diesem Beispiel enthält derenv
-Kontext zwei Variablen.
{
"first_name": "Mona",
"super_duper_var": "totally_awesome"
}
Beispielverwendung des env
-Kontexts
Dieser Beispielworkflow zeigt Variablen, die im env
-Kontext auf Workflow-, Auftrags- und Schrittebene festgelegt werden. Die ${{ env.VARIABLE-NAME }}
-Syntax wird dann zum Abrufen von Variablenwerten innerhalb einzelner Schritte im Workflow verwendet.
Wenn mehr als eine Umgebungsvariable mit dem gleichen Namen definiert ist, verwendet GitHub die spezifischste Variable. Beispielsweise setzt eine in einem Schritt definierte Umgebungsvariable Auftrags- und Workflowumgebungsvariablen mit demselben Namen außer Kraft, während der Schritt ausgeführt wird. Eine für einen Auftrag definierte Umgebungsvariable setzt eine Workflowvariable mit demselben Namen außer Kraft, während der Auftrag ausgeführt wird.
name: Hi Mascot on: push env: mascot: Mona super_duper_var: totally_awesome jobs: windows_job: runs-on: windows-latest steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Mona - run: echo 'Hi ${{ env.mascot }}' # Hi Octocat env: mascot: Octocat linux_job: runs-on: ubuntu-latest env: mascot: Tux steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Tux
name: Hi Mascot
on: push
env:
mascot: Mona
super_duper_var: totally_awesome
jobs:
windows_job:
runs-on: windows-latest
steps:
- run: echo 'Hi ${{ env.mascot }}' # Hi Mona
- run: echo 'Hi ${{ env.mascot }}' # Hi Octocat
env:
mascot: Octocat
linux_job:
runs-on: ubuntu-latest
env:
mascot: Tux
steps:
- run: echo 'Hi ${{ env.mascot }}' # Hi Tux
Kontext vars
Hinweis: Konfigurationsvariablen für GitHub Actions befinden sich in der beta und können geändert werden.
Der vars
-Kontext enthält benutzerdefinierte Konfigurationsvariablen, die auf Organisations-, Repository- und Umgebungsebene festgelegt sind. Weitere Informationen zum Definieren von Konfigurationsvariablen für die Verwendung in mehreren Workflows finden Sie unter Speichern von Informationen in Variablen.
Beispielinhalt des vars
-Kontexts
Der Inhalt des vars
-Kontexts ist eine Zuordnung der Namen von Konfigurationsvariablen zu ihren Werten.
{
"mascot": "Mona"
}
Beispielverwendung des vars
-Kontexts
Dieser Beispielworkflow zeigt, wie Konfigurationsvariablen, die auf Repository-, Umgebungs- oder Organisationsebene festgelegt werden, automatisch über den vars
-Kontext verfügbar sind.
Wenn keine Konfigurationsvariable festgelegt wurde, ist der Rückgabewert eines Kontexts, der auf die Variable verweist, eine leere Zeichenfolge.
Das folgende Beispiel zeigt die Verwendung von Konfigurationsvariablen mit dem Kontext vars
in einem Workflow. Jede der folgenden Konfigurationsvariablen wurde auf Repository-, Organisations- oder Umgebungsebene definiert.
on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }}
on:
workflow_dispatch:
env:
# Setting an environment variable with the value of a configuration variable
env_var: ${{ vars.ENV_CONTEXT_VAR }}
jobs:
display-variables:
name: ${{ vars.JOB_NAME }}
# You can use configuration variables with the `vars` context for dynamic jobs
if: ${{ vars.USE_VARIABLES == 'true' }}
runs-on: ${{ vars.RUNNER }}
environment: ${{ vars.ENVIRONMENT_STAGE }}
steps:
- name: Use variables
run: |
echo "repository variable : $REPOSITORY_VAR"
echo "organization variable : $ORGANIZATION_VAR"
echo "overridden variable : $OVERRIDE_VAR"
echo "variable from shell environment : $env_var"
env:
REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
- name: ${{ vars.HELLO_WORLD_STEP }}
if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
uses: actions/hello-world-javascript-action@main
with:
who-to-greet: ${{ vars.GREET_NAME }}
Kontext job
Der job
-Kontext enthält Informationen zum derzeit ausgeführten Auftrag.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
job | object | Dieser Kontext ändert sich bei jedem Auftrag in einem Workflow-Lauf. Sie können bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
job.container | object | Informationen zum Container des Auftrags. Weitere Informationen zu Containern finden Sie unter Workflowsyntax für GitHub Actions. |
job.container.id | string | ID des Containers. |
job.container.network | string | ID des Containernetzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
job.services | object | Die für einen Auftrag erstellten Dienstcontainer. Weitere Informationen zu Dienstcontainern finden Sie unter Workflowsyntax für GitHub Actions. |
job.services.<service_id>.id | string | ID des Dienstcontainers. |
job.services.<service_id>.network | string | ID des Dienstcontainernetzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
job.services.<service_id>.ports | object | Die offengelegten Ports des Service-Containers |
job.status | string | Den aktuellen Status des Auftrags. Mögliche Werte sind success , failure oder cancelled . |
Beispielinhalt des job
-Kontexts
In diesem job
-Beispielkontext wird ein PostgreSQL-Dienstcontainer mit zugeordneten Ports verwendet. Werden in einem Auftrag keine Container oder Dienstcontainer verwendet, enthält der job
-Kontext nur die Eigenschaft status
.
{
"status": "success",
"container": {
"network": "github_network_53269bd575974817b43f4733536b200c"
},
"services": {
"postgres": {
"id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105",
"ports": {
"5432": "49153"
},
"network": "github_network_53269bd575974817b43f4733536b200c"
}
}
}
Beispielverwendung des job
-Kontexts
In diesem Beispielworkflow wird ein PostgreSQL-Dienstcontainer konfiguriert und Port 5432 im Dienstcontainer automatisch einem zufällig ausgewählten verfügbaren Port auf dem Host zugeordnet. Mit dem job
-Kontext wird auf die Nummer des Ports zugegriffen, der dem Host zugewiesen wurde.
name: PostgreSQL Service Example on: push jobs: postgres-job: runs-on: ubuntu-latest services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 ports: # Maps TCP port 5432 in the service container to a randomly chosen available port on the host. - 5432 steps: - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }} - run: echo "Run tests against Postgres"
name: PostgreSQL Service Example
on: push
jobs:
postgres-job:
runs-on: ubuntu-latest
services:
postgres:
image: postgres
env:
POSTGRES_PASSWORD: postgres
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
ports:
# Maps TCP port 5432 in the service container to a randomly chosen available port on the host.
- 5432
steps:
- run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
- run: echo "Run tests against Postgres"
Kontext jobs
Der Kontext jobs
ist nur in wiederverwendbaren Workflows verfügbar und kann nur verwendet werden, um Ausgaben für einen wiederverwendbaren Workflow festzulegen. Weitere Informationen finden Sie unter Wiederverwenden von Workflows.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
jobs | object | Ist ausschließlich in wiederverwendbaren Workflows verfügbar und kann nur verwendet werden, um Ausgaben für einen wiederverwendbaren Workflow festzulegen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
jobs.<job_id>.result | string | Das Ergebnis eines Auftrags im wiederverwendbaren Workflow. Mögliche Werte sind success , failure , cancelled oder skipped . |
jobs.<job_id>.outputs | object | Der Ausgabensatz eines Auftrags in einem wiederverwendbaren Workflow. |
jobs.<job_id>.outputs.<output_name> | string | Der Wert einer spezifischen Ausgabe für einen Auftrag in einem wiederverwendbaren Workflow. |
Beispielinhalt des jobs
-Kontexts
Dieses Beispiel für den Kontext jobs
enthält das Ergebnis und die Ausgaben eines Auftrags aus einer wiederverwendbaren Workflowausführung.
{
"example_job": {
"result": "success",
"outputs": {
"output1": "hello",
"output2": "world"
}
}
}
Beispielverwendung des jobs
-Kontexts
In diesem Beispiel für einen wiederverwendbaren Workflow wird der jobs
-Kontext verwendet, um Ausgaben für den wiederverwendbaren Workflow festzulegen. Beachte, wie die Ausgaben von den Schritten zum Auftrag und dann zum Trigger workflow_call
fließen. Weitere Informationen finden Sie unter Wiederverwenden von Workflows.
name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT
name: Reusable workflow
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.firstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "firstword=hello" >> $GITHUB_OUTPUT
- id: step2
run: echo "secondword=world" >> $GITHUB_OUTPUT
Kontext steps
Der steps
-Kontext enthält Informationen zu den Schritten im aktuellen Auftrag, die über einen angegebenen id
-Wert verfügen und bereits ausgeführt wurden.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
steps | object | Dieser Kontext ändert sich bei jedem Schritt in einem Auftrag. Sie können bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
steps.<step_id>.outputs | object | Der Satz an Ausgaben, die für diesen Schritt definiert wurden. Weitere Informationen finden Sie unter Metadatensyntax für GitHub Actions. |
steps.<step_id>.conclusion | string | Ergebnis eines abgeschlossenen Schritts nach der Anwendung von continue-on-error . Mögliche Werte sind success , failure , cancelled oder skipped . Tritt bei einem Schritt vom Typ continue-on-error ein Fehler auf, lautet der outcome -Wert failure , doch der endgültige conclusion -Wert lautet success . |
steps.<step_id>.outcome | string | Ergebnis eines abgeschlossenen Schritts vor der Anwendung von continue-on-error . Mögliche Werte sind success , failure , cancelled oder skipped . Tritt bei einem Schritt vom Typ continue-on-error ein Fehler auf, lautet der outcome -Wert failure , doch der endgültige conclusion -Wert lautet success . |
steps.<step_id>.outputs.<output_name> | string | Der Wert einer bestimmten Ausgabe |
Beispielinhalt des steps
-Kontexts
In diesem steps
-Beispielkontext siehst du zwei zuvor ausgeführte Schritte mit angegebenem id
-Wert. Der id
-Wert des ersten Schritts lautete checkout
, der des zweiten Schritts generate_number
. Die Ausgabe des Schritts generate_number
lautete random_number
.
{
"checkout": {
"outputs": {},
"outcome": "success",
"conclusion": "success"
},
"generate_number": {
"outputs": {
"random_number": "1"
},
"outcome": "success",
"conclusion": "success"
}
}
Beispielverwendung des steps
-Kontexts
In diesem Beispielworkflow wird als Ausgabe in einem Schritt eine Zufallszahl generiert, deren Wert in einem späteren Schritt mit dem steps
-Kontext gelesen wird.
name: Generate random failure on: push jobs: randomly-failing-job: runs-on: ubuntu-latest steps: - name: Generate 0 or 1 id: generate_number run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT - name: Pass or fail run: | if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
name: Generate random failure
on: push
jobs:
randomly-failing-job:
runs-on: ubuntu-latest
steps:
- name: Generate 0 or 1
id: generate_number
run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT
- name: Pass or fail
run: |
if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
Kontext runner
Der runner
-Kontext enthält Informationen zum Runner, der den aktuellen Auftrag ausführt.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
runner | object | Dieser Kontext ändert sich bei jedem Auftrag in einem Workflow-Lauf. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
runner.name | string | Der Name des Runners, der den Auftrag ausführt. Dieser Name ist in einem Workflow-Lauf möglicherweise nicht eindeutig, da Runner auf Repository- und Organisationsebene denselben Namen verwenden könnten. |
runner.os | string | Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind Linux , Windows oder macOS . |
runner.arch | string | Die Architektur des Runners, der den Auftrag ausführt. Mögliche Werte sind X86 , X64 , ARM oder ARM64 . |
runner.temp | string | Der Pfad zu einem temporären Verzeichnis im Runner. Dieses Verzeichnis wird jeweils zu Beginn und am Ende eines Auftrags geleert. Hinweis: Wenn das Benutzerkonto des Runners über keine Berechtigung zum Löschen verfügt, werden keine Dateien entfernt. |
runner.tool_cache | string | Der Pfad zu dem Verzeichnis, das vorinstallierte Tools für von GitHub gehostete Runner enthält. Weitere Informationen findest du unter Verwenden von auf GitHub gehosteten Runnern. |
runner.debug | string | Dies ist nur festgelegt, wenn die Debugprotokollierung aktiviert ist, und weist immer den Wert 1 auf. Es kann ein nützlicher Hinweis darauf sein, ob in deinen Auftragsschritten zusätzliches Debugging oder eine ausführliche Protokollierung aktiviert werden sollte. |
runner.environment | string | Die Umgebung des Runners, der den Auftrag ausführt. Mögliche Werte sind github-hosted für von GitHub gehostete Runner, die von GitHub bereitgestellt werden, und self-hosted für selbst gehostete Runner, die vom Repositorybesitzer konfiguriert werden. |
Beispielinhalt des runner
-Kontexts
Der folgende Beispielkontext stammt von einem unter Linux gehosteten GitHub-Runner.
{
"os": "Linux",
"arch": "X64",
"name": "GitHub Actions 2",
"tool_cache": "/opt/hostedtoolcache",
"temp": "/home/runner/work/_temp"
}
Beispielverwendung des runner
-Kontexts
In diesem Beispielworkflow wird mit dem runner
-Kontext der Pfad zum temporären Verzeichnis zum Schreiben von Protokollen festgelegt. Bei einem Fehler in der Workflowausführung werden diese Protokolle als Artefakt hochgeladen.
name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build with logs run: | mkdir ${{ runner.temp }}/build_logs echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs exit 1 - name: Upload logs on fail if: ${{ failure() }} uses: actions/upload-artifact@v3 with: name: Build failure logs path: ${{ runner.temp }}/build_logs
name: Build
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build with logs
run: |
mkdir ${{ runner.temp }}/build_logs
echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs
exit 1
- name: Upload logs on fail
if: ${{ failure() }}
uses: actions/upload-artifact@v3
with:
name: Build failure logs
path: ${{ runner.temp }}/build_logs
Kontext secrets
Der secrets
-Kontext enthält die Namen und Werte von Geheimnissen, die für eine Workflowausführung verfügbar sind. Der secrets
-Kontext ist aus Sicherheitsgründen nicht für zusammengesetzte Aktionen verfügbar. Wenn du ein Geheimnis an eine zusammengesetzte Aktion übergeben möchtest, musst du es explizit als Eingabe übergeben. Weitere Informationen zu Geheimnissen finden Sie unter Verwenden von Geheimnissen in GitHub-Aktionen.
Das Geheimnis GITHUB_TOKEN
wird automatisch für jede Workflowausführung erstellt und ist in jedem secrets
-Kontext enthalten. Weitere Informationen finden Sie unter Automatische Tokenauthentifizierung.
Warnung: Wenn in der Aufgabe ein Geheimnis verwendet wurde, werden GitHub automatisch die in das Protokoll ausgegebenen Geheimnisse unkenntlich gemacht. Sie sollten die Geheimnisse nicht absichtlich in das Protokoll ausgeben.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
secrets | object | Dieser Kontext ist für jeden Auftrag in einer Workflowausführung identisch. Sie können bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
secrets.GITHUB_TOKEN | string | Automatisch erstelltes Token für jede Workflowausführung. Weitere Informationen finden Sie unter Automatische Tokenauthentifizierung. |
secrets.<secret_name> | string | Wert eines bestimmten Geheimnisses. |
Beispielinhalt des secrets
-Kontexts
Im folgenden Beispielinhalt des secrets
-Kontexts siehst du das automatisch generierte Geheimnis GITHUB_TOKEN
sowie zwei weitere Geheimnisse, die für die Workflowausführung verfügbar sind.
{
"github_token": "***",
"NPM_TOKEN": "***",
"SUPERSECRET": "***"
}
Beispielverwendung des secrets
-Kontexts
In diesem Beispielworkflow wird die GitHub CLI verwendet, die das GITHUB_TOKEN
als Wert für den GH_TOKEN
-Eingabeparameter erfordert:
name: Open new issue on: workflow_dispatch jobs: open-issue: runs-on: ubuntu-latest permissions: contents: read issues: write steps: - run: | gh issue --repo ${{ github.repository }} \ create --title "Issue title" --body "Issue body" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
name: Open new issue
on: workflow_dispatch
jobs:
open-issue:
runs-on: ubuntu-latest
permissions:
contents: read
issues: write
steps:
- run: |
gh issue --repo ${{ github.repository }} \
create --title "Issue title" --body "Issue body"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Kontext strategy
Für Workflows mit einer Matrix enthält der strategy
-Kontext Informationen zur Ausführungsstrategie der Matrix für den aktuellen Auftrag.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
strategy | object | Dieser Kontext ändert sich bei jedem Auftrag in einem Workflow-Lauf. Auf diesen Kontext können Sie von jedem Auftrag oder Schritt in einem Workflow zugreifen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
strategy.fail-fast | boolean | Wenn dies true ergibt, werden alle ausgeführten Aufträge abgebrochen, nachdem bei einem Auftrag in einer Matrix ein Fehler aufgetreten ist. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions. |
strategy.job-index | number | Index des aktuellen Auftrags in der Matrix. Hinweis: Diese Zahl ist nullbasiert. Der Index des ersten Auftrags in der Matrix ist 0 . |
strategy.job-total | number | Die Gesamtanzahl der Aufträge in der Matrix. Hinweis: Diese Zahl ist nicht nullbasiert. Für eine Matrix mit vier Aufträgen ist der Wert von job-total z. B. 4 . |
strategy.max-parallel | number | Maximale Anzahl der Aufträge, die bei Verwendung einer matrix -Auftragsstrategie gleichzeitig ausgeführt werden können. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions. |
Beispielinhalt des strategy
-Kontexts
Der folgende Beispielinhalt des strategy
-Kontexts stammt aus dem letzten Auftrag einer Matrix mit vier Aufträgen. Wie du siehst, unterscheidet sich die nullbasierte Anzahl für job-index
von der nicht nullbasierten Anzahl für job-total
.
{
"fail-fast": true,
"job-index": 3,
"job-total": 4,
"max-parallel": 4
}
Beispielverwendung des strategy
-Kontexts
In diesem Beispielworkflow wird mit der Eigenschaft strategy.job-index
ein eindeutiger Name für eine Protokolldatei für jeden Auftrag in einer Matrix festgelegt.
name: Test strategy on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: test-group: [1, 2] node: [14, 16] steps: - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt - name: Upload logs uses: actions/upload-artifact@v3 with: name: Build log for job ${{ strategy.job-index }} path: test-job-${{ strategy.job-index }}.txt
name: Test strategy
on: push
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
test-group: [1, 2]
node: [14, 16]
steps:
- run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt
- name: Upload logs
uses: actions/upload-artifact@v3
with:
name: Build log for job ${{ strategy.job-index }}
path: test-job-${{ strategy.job-index }}.txt
Kontext matrix
Für Workflows mit einer Matrix enthält der matrix
-Kontext die Matrixeigenschaften, die in der Workflowdatei für den aktuellen Auftrag definiert sind. Wenn du z. B. eine Matrix mit den Schlüsseln os
und node
konfigurierst, enthält das matrix
-Kontextobjekt die Eigenschaften os
und node
mit den Werten, die für den aktuellen Auftrag verwendet werden.
Der matrix
-Kontext enthält nur die in der Workflowdatei definierten Eigenschaften, keine Standardeigenschaften.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
matrix | object | Dieser Kontext ist nur für Aufträge in einer Matrix verfügbar und unterscheidet sich für jeden Auftrag in einer Workflowausführung. Auf diesen Kontext können Sie von jedem Auftrag oder Schritt in einem Workflow zugreifen. Dieses Objekt enthält die unten aufgeführten Eigenschaften. |
matrix.<property_name> | string | Wert einer Matrixeigenschaft. |
Beispielinhalt des matrix
-Kontexts
Der folgende Beispielinhalt des matrix
-Kontexts stammt aus einem Auftrag in einer Matrix, die die im Workflow definierten Matrixeigenschaften os
und node
aufweist. Der Auftrag führt die Matrixkombination aus einem ubuntu-latest
-Betriebssystem und Version 16
von Node.js aus.
{
"os": "ubuntu-latest",
"node": 16
}
Beispielverwendung des matrix
-Kontexts
In diesem Beispielworkflow wird eine Matrix mit den Schlüsseln os
und node
erstellt. Mit der Eigenschaft matrix.os
wird der Runnertyp und mit der Eigenschaft matrix.node
die Version von Node.js für jeden Auftrag festgelegt.
name: Test matrix on: push jobs: build: runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-latest, windows-latest] node: [14, 16] steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version
name: Test matrix
on: push
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- name: Output node version
run: node --version
Kontext needs
Der needs
-Kontext enthält Ausgaben aller Aufträge, die als direkte Abhängigkeit des aktuellen Auftrags definiert sind. Beachte, dass das nicht für implizit abhängige Aufträge gilt (z. B. abhängige Aufträge eines abhängigen Auftrags). Weitere Informationen zum Definieren von Auftragsabhängigkeiten finden Sie unter Workflowsyntax für GitHub Actions.
Eigenschaftenname | Type | BESCHREIBUNG |
---|---|---|
needs | object | Dieser Kontext wird nur für Workflowausführungen mit abhängigen Aufträgen ausgefüllt und unterscheidet sich für jeden Auftrag in einer Workflowausführung. Auf diesen Kontext können Sie von jedem Auftrag oder Schritt in einem Workflow zugreifen. Dieses Objekt enthält alle unten aufgeführten Eigenschaften. |
needs.<job_id> | object | Ein einzelner Job, von dem der aktuelle Job abhängt. |
needs.<job_id>.outputs | object | Die Menge aller Ausgaben eines Jobs, von dem der aktuelle Job abhängt. |
needs.<job_id>.outputs.<output name> | string | Der Wert einer bestimmten Ausgabe für einen Job, von dem der aktuelle Job abhängt. |
needs.<job_id>.result | string | Das Ergebnis eines Jobs, von dem der aktuelle Job abhängt. Mögliche Werte sind success , failure , cancelled oder skipped . |
Beispielinhalt des needs
-Kontexts
Im folgenden Beispielinhalt des needs
-Kontexts siehst du Informationen für zwei Aufträge, von denen der aktuelle Auftrag abhängt.
{
"build": {
"result": "success",
"outputs": {
"build_id": "123456"
}
},
"deploy": {
"result": "failure",
"outputs": {}
}
}
Beispielverwendung des needs
-Kontexts
Dieser Beispielworkflow verfügt über drei Aufträge: einen build
-Auftrag, der einen Build ausführt, einen deploy
-Auftrag, für den der build
-Auftrag benötigt wird, und einen debug
-Auftrag, für den die Aufträge build
und deploy
benötigt werden und der nur bei einem Fehler im Workflow ausgeführt wird. Der deploy
-Auftrag verwendet den needs
-Kontext auch, um auf eine Ausgabe aus dem build
-Auftrag zuzugreifen.
name: Build and deploy on: push jobs: build: runs-on: ubuntu-latest outputs: build_id: ${{ steps.build_step.outputs.build_id }} steps: - name: Build id: build_step run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT deploy: needs: build runs-on: ubuntu-latest steps: - run: echo "Deploying build ${{ needs.build.outputs.build_id }}" debug: needs: [build, deploy] runs-on: ubuntu-latest if: ${{ failure() }} steps: - run: echo "Failed to build and deploy"
name: Build and deploy
on: push
jobs:
build:
runs-on: ubuntu-latest
outputs:
build_id: ${{ steps.build_step.outputs.build_id }}
steps:
- name: Build
id: build_step
run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- run: echo "Deploying build ${{ needs.build.outputs.build_id }}"
debug:
needs: [build, deploy]
runs-on: ubuntu-latest
if: ${{ failure() }}
steps:
- run: echo "Failed to build and deploy"
Kontext inputs
Der Kontext inputs
enthält Eingabeeigenschaften, die an eine Aktion, einen wiederverwendbaren Workflow oder einen manuell ausgelösten Workflow übergeben werden. Für wiederverwendbare Workflows werden die Eingabenamen und -typen in der Konfiguration des workflow_call
-Ereignisses eines wiederverwendbaren Workflows definiert. Die Eingabewerte werden von jobs.<job_id>.with
in einem externen Workflow übergeben, der den wiederverwendbaren Workflow aufruft. Für manuell ausgelöste Workflows werden die Eingaben in der Konfiguration des workflow_dispatch
-Ereignisses eines Workflows definiert.
Die Eigenschaften im inputs
-Kontext werden in der Workflowdatei definiert. Sie sind nur in einem wiederverwendbaren Workflowoder in einem durch das Ereignis workflow_dispatch
ausgelösten Workflow verfügbar.
Eigenschaftenname | Type | Beschreibung |
---|---|---|
inputs | object | Dieser Kontext ist nur in einem wiederverwendbaren Workflow oder in einem Workflow, der von dem workflow_dispatch -Ereignis ausgelöst wurde, verfügbar. Auf diesen Kontext können Sie von jedem Auftrag oder Schritt in einem Workflow zugreifen. Dieses Objekt enthält die unten aufgeführten Eigenschaften. |
inputs.<name> | string oder number oder boolean oder choice | Jeder Eingabewert, der von einem externen Workflow übergeben wurde. |
Beispielinhalt des inputs
-Kontexts
Der folgende Beispielinhalt des inputs
-Kontexts stammt aus einem Workflow, der die Eingaben build_id
, deploy_target
und perform_deploy
definiert hat.
{
"build_id": 123456768,
"deploy_target": "deployment_sys_1a",
"perform_deploy": true
}
Beispielnutzung des inputs
-Kontexts in einem wiederverwendbaren Workflow
In diesem Beispiel eines wiederverwendbaren Workflows werden mit dem inputs
-Kontext die Werte der Eingaben build_id
, deploy_target
und perform_deploy
abgerufen, die an den wiederverwendbaren Workflow vom aufrufenden Workflow übergeben wurden.
name: Reusable deploy workflow on: workflow_call: inputs: build_id: required: true type: number deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
name: Reusable deploy workflow
on:
workflow_call:
inputs:
build_id:
required: true
type: number
deploy_target:
required: true
type: string
perform_deploy:
required: true
type: boolean
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ inputs.perform_deploy }}
steps:
- name: Deploy build to target
run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
Beispielnutzung des inputs
-Kontexts in einem manuell ausgelösten Workflow
In diesem Beispiel eines durch ein workflow_dispatch
-Ereignis ausgelösten Workflows werden mit dem inputs
-Kontext die Werte der Eingaben build_id
, deploy_target
und perform_deploy
abgerufen, die an den Workflow übergeben wurden.
on: workflow_dispatch: inputs: build_id: required: true type: string deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
on:
workflow_dispatch:
inputs:
build_id:
required: true
type: string
deploy_target:
required: true
type: string
perform_deploy:
required: true
type: boolean
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ inputs.perform_deploy }}
steps:
- name: Deploy build to target
run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"