# Kontextreferenz Hier finden Sie Informationen zu Kontexten, die in GitHub Actions Workflows verfügbar sind, einschließlich verfügbarer Eigenschaften, Zugriffsmethoden und Verwendungsbeispielen. ## Verfügbare Kontexte | Kontextname | Typ | BESCHREIBUNG | | ----------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | Informationen zum Workflow-Durchlauf. Weitere Informationen finden Sie unter [Kontext `github`](#github-context). | | `env` | `object` | Enthält Variablen, die in einem Workflow, Auftrag oder Schritt festgelegt sind. Weitere Informationen finden Sie unter [Kontext `env`](#env-context). | | `vars` | `object` | Enthält Variablen, die auf Repository-, Organisations- und Umgebungsebene festgelegt sind. Weitere Informationen finden Sie unter [Kontext `vars`](#vars-context). | | `job` | `object` | Informationen zum derzeit ausgeführten Auftrag. Weitere Informationen finden Sie unter [Kontext `job`](#job-context). | | `jobs` | `object` | Nur für wiederverwendbare Workflows. Enthält Ausgaben von Aufträgen aus dem wiederverwendbaren Workflow. Weitere Informationen finden Sie unter [Kontext `jobs`](#jobs-context). | | `steps` | `object` | Informationen zu den Schritten, die im aktuellen Job ausgeführt wurden. Weitere Informationen finden Sie unter [Kontext `steps`](#steps-context). | | `runner` | `object` | Informationen zum Runner, der den aktuellen Auftrag ausführt. Weitere Informationen finden Sie unter [Kontext `runner`](#runner-context). | | `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`](#secrets-context). | | `strategy` | `object` | Informationen zur Ausführungsstrategie der Matrix für den aktuellen Auftrag. Weitere Informationen finden Sie unter [Kontext `strategy`](#strategy-context). | | `matrix` | `object` | Enthält die im Workflow definierten Matrixeigenschaften, die für den aktuellen Auftrag gelten. Weitere Informationen finden Sie unter [Kontext `matrix`](#matrix-context). | | `needs` | `object` | Enthält die Ergebnisse aller Aufträge, die als Abhängigkeit des aktuellen Auftrags definiert sind. Weitere Informationen finden Sie unter [Kontext `needs`](#needs-context). | | `inputs` | `object` | Enthält die Eingaben eines wiederverwendbaren oder manuell ausgelösten Workflows. Weitere Informationen finden Sie unter [Kontext `inputs`](#inputs-context). | 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. ### Festlegen, wann Kontexte verwendet werden GitHub Actions enthält eine Auflistung von Variablen, die als *Kontexte* bezeichnet werden, und eine ähnliche Auflistung von Variablen, die als *Standardvariablen* bezeichnet werden. Diese Variablen sind zur Verwendung an verschiedenen Stellen im Workflow gedacht. * **Standardumgebungsvariablen:** Diese Umgebungsvariablen sind nur auf dem Runner vorhanden, der deinen Auftrag ausführt. Weitere Informationen finden Sie unter [Referenz für Variablen](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/variables). * **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 wie `runner.os`. Ausführliche Informationen dazu, wo du bestimmte Kontexte innerhalb eines Workflows verwenden kannst, findest du unter [Kontextverfügbarkeit](#context-availability). Im folgenden Beispiel wird veranschaulicht, wie diese verschiedenen Variablentypen in einem Auftrag zusammen verwendet werden können: ```yaml copy 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`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) aktuellen Zweignamen zu ermitteln; wenn der Name `refs/heads/main` lautet, werden die nachfolgenden Schritte ausgeführt. Die `if` Prüfung wird von GitHub Actions bearbeitet, und der Auftrag wird nur an den Runner gesendet, wenn `true` das Ergebnis ist. Sobald der Auftrag an den Runner gesendet wird, wird der Schritt ausgeführt und verweist auf die [`$GITHUB_REF`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/variables)-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. Die folgende Tabelle enthält die Einschränkungen dafür, an welchen Stellen die einzelnen Kontexte und Sonderfunktionen innerhalb eines Workflows verwendet werden können. Die aufgeführten Kontexte stehen nur für den angegebenen Workflowschlüssel zur Verfügung und werden möglicherweise nicht an anderer Stelle verwendet. 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` | Keine | | `env` | `github, secrets, inputs, vars` | Keine | | `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | Keine | | `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | Keine | | `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | Keine | | `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | Keine | | `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | Keine | | `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | Keine | | `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | Keine | | `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` | | `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | Keine | | `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | Keine | | `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | Keine | | `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | Keine | | `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` | | `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..strategy` | `github, needs, vars, inputs` | Keine | | `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | Keine | | `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | Keine | | `on.workflow_call.inputs..default` | `github, inputs, vars` | Keine | | `on.workflow_call.outputs..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 [`toJSON`-Funktion](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#tojson) wird benötigt, um JSON-Objekte in das Protokoll zu drucken. > \[!WARNING] > Bedenke beim Verwenden des gesamten `github`-Kontexts, 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. ```yaml copy 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 kannst du in Umgebungsvariablen lesen. Weitere Informationen zu Umgebungsvariablen findest du unter [Speichern von Informationen in Variablen](/de/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables). > \[!WARNING] > Bedenke beim Verwenden des gesamten `github`-Kontexts, 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. > \[!WARNING] > Beim Erstellen von Workflows und Aktionen sollten Sie immer berücksichtigen, ob Ihr Code möglicherweise Code aus nicht vertrauenswürdigen Eingaben potenzieller Angreifer ausführt. Bestimmte Kontexte sollten als nicht vertrauenswürdige Eingaben behandelt werden, da ein Angreifer seine eigenen schädlichen Inhalte einfügen könnte. Weitere Informationen finden Sie unter [Referenz zur sicheren Verwendung](/de/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks). | Eigenschaftsname | Typ | 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`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid)-Wert eines Schritts. | | GitHub entfernt Sonderzeichen und setzt den Namen `__run` ein, wenn der aktuelle Schritt ein Skript ohne ein `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` | Der Pfad, wo sich eine Aktion befindet. Diese Eigenschaft wird nur in Kompositaktionen unterstützt. Sie können diesen Pfad verwenden, um auf Dateien zuzugreifen, die sich im selben Repository wie die Aktion befinden, z. B. indem Sie Verzeichnisse in den Pfad ändern (unter Verwendung der entsprechenden Umgebungsvariable): `cd "$GITHUB_ACTION_PATH"`. Weitere Informationen zu Umgebungsvariablen finden Sie unter [Referenz zur sicheren Verwendung](/de/enterprise-server@3.22/actions/reference/security/secure-use#use-an-intermediate-environment-variable). | | `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` | Die 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 einzigartig und unterscheidet sich für jeden Schritt eines Auftrags. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable). | | `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 dem Webhook-Payload des Events, das die Ausführung des Workflows ausgelöst hat, und unterscheidet sich für jedes Event. Die Webhooks für jedes GitHub Actions Ereignis werden in [Ereignisse zum Auslösen von Workflows](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) verknüpft. Für einen Workflow, der vom [Ereignis `push`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#push) ausgelöst wird, enthält dieses Objekt beispielsweise den Inhalt der [Push-Webhook-Nutzlast](/de/enterprise-server@3.22/webhooks/webhook-events-and-payloads#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` | Die 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` | Die [`job_id`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_id) des aktuellen Jobs.
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 einzigartig und unterscheidet sich für jeden Schritt eines Auftrags. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path). | | `github.ref` | `string` | Das vollständige Ref des Branches oder Tags, das die Workflow-Ausführung ausgelöst hat. Bei Workflows, die durch `push` ausgelöst wurden, ist dies das Branch- oder Tag-Ref, das gepusht wurde. Für Workflows, die von `pull_request` ausgelöst wurden und nicht zusammengeführt wurden, ist dies der Merge-Branch der Pull-Anfrage. Wenn die Pullanforderung zusammengeführt wurde, ist dies die Verzweigung, in die sie zusammengeführt wurde. Bei Workflows, die von `release` ausgelöst werden, ist dies das erstellte Releasetag. Bei anderen Triggern handelt es sich um die Branch- oder Tag-Referenz, die den Workflow-Ablauf ausgelöst hat. Es wird nur gesetzt, wenn für den betreffenden Ereignistyp ein Branch oder ein Tag verfügbar ist. Der angegebene Bezug ist vollständig formatiert, d. h. für Branches ist `refs/heads/` das Format. Bei Pull-Request-Ereignissen, außer `pull_request_target`, die nicht zusammengeführt wurden, ist es `refs/pull//merge`. | | `pull_request_target`-Ereignisse haben `ref` aus dem Basis-Branch. Für Tags ist es `refs/tags/`. Beispiel: `refs/heads/feature-branch-1`. Weitere Informationen zu den Zusammenführungsbranches von Pull-Anfragen finden Sie unter [Pull-Anfragen](/de/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). | | | | `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 Pullanforderungen, die nicht zusammengeführt wurden, lautet das Format `/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 finden Sie unter [Ereignisse zum Auslösen von Workflows](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). Beispiel: `ffac537e6cbbf934b08745a378932722df287a53`. | | `github.token` | `string` | Token zur Authentifizierung im Namen der in Ihrem Repository installierten GitHub-App. Dies ist funktional gleichwertig mit dem Geheimnis `GITHUB_TOKEN`. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token).
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` | Das Standard-Arbeitsverzeichnis des Runners für Schritte und der Standard-Speicherort deines Repositorys, wenn du die [`checkout`](https://github.com/actions/checkout)-Aktion verwendest. | ### 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 [Webhook-Nutzlast `push`](/de/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push) identisch ist. > \[!NOTE] > Dieser Kontext dient lediglich als Beispiel. Der Inhalt eines Kontexts hängt vom ausgeführten Workflow ab. Kontexte, Objekte und Eigenschaften variieren bei verschiedenen Workflowausführungsbedingungen erheblich. ```json { "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. ```yaml copy 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 findest du unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env). 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 in jedem beliebigen Schlüsselschritt verwenden, ausgenommen die Schlüssel `id` und `uses`. Weitere Informationen zur Schrittsyntax findest du unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsteps). 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. | Eigenschaftsname | Typ | 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.` | `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 Stelle im Workflow-Lauf kann der Inhalt des Kontexts variieren. In diesem Beispiel enthält der`env`-Kontext zwei Variablen. ```json { "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. ```yaml copy 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` 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 findest du unter [Speichern von Informationen in Variablen](/de/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows). ### Beispielinhalt des `vars`-Kontexts Der Inhalt des `vars`-Kontexts ist eine Zuordnung der Namen von Konfigurationsvariablen zu ihren Werten. ```json { "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. > \[!NOTE] > Konfigurationsvariablen auf Umgebungsebene sind automatisch verfügbar, nachdem ihre Umgebung vom Runner deklariert wurde. 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. ```yaml copy 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. | Eigenschaftsname | Typ | 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 findest du unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer). | | `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 Job genutzt wird. | | `job.services` | `object` | Die für einen Auftrag erstellten Dienstcontainer. Weitere Informationen zu Dienstcontainern findest du unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices). | | `job.services..id` | `string` | ID des Dienstcontainers. | | `job.services..network` | `string` | ID des Dienstcontainernetzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Job genutzt wird. | | `job.services..ports` | `object` | Die offengelegten Ports des Service-Containers | | `job.status` | `string` | Den aktuellen Status des Auftrags. Mögliche Werte sind `success`, `failure` oder `cancelled`. | | `job.workflow_ref` | `string` | Die vollständige Referenz der Workflow-Datei, in der der aktuelle Job definiert ist. Beispiel: `octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`. Für Aufträge, die direkt in einer Workflowdatei definiert sind, ist dies identisch mit `github.workflow_ref`. Bei Aufträgen, die in einem [Wiederverwenden von Workflows](/de/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) definiert sind, bezieht sich dies auf die wiederverwendbare Workflowdatei. (nicht verfügbar auf GitHub Enterprise Server) | | `job.workflow_sha` | `string` | Der Commit-SHA der Workflowdatei, die den aktuellen Job definiert. (nicht verfügbar auf GitHub Enterprise Server) | | `job.workflow_repository` | `string` | Der `owner/repo` des Repositorys, das die Workflow-Datei enthält, die den aktuellen Auftrag definiert. Beispiel: `octo-org/octo-repo`. (nicht verfügbar auf GitHub Enterprise Server) | | `job.workflow_file_path` | `string` | Der Dateipfad der Workflow-Datei, die den aktuellen Job definiert, relativ zum Stammverzeichnis des Repositorys. Beispiel: `.github/workflows/deploy.yml`. (nicht verfügbar auf GitHub Enterprise Server) | ### Beispielinhalt des `job`-Kontexts In diesem `job`-Beispielkontext wird ein PostgreSQL-Dienstcontainer mit zugeordneten Ports verwendet. Wenn in einem Job keine Container oder Dienst-Container verwendet werden, enthält der `job`-Kontext nur `status`. Die `check_run_id`- und Workflow-Identitätseigenschaften (`workflow_ref`, `workflow_sha`, `workflow_repository`, `workflow_file_path`) sind nicht auf GitHub Enterprise Server verfügbar. ```json { "status": "success", "check_run_id": 51725241954, "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main", "workflow_sha": "abc123def456789abc123def456789abc123def4", "workflow_repository": "octo-org/octo-repo", "workflow_file_path": ".github/workflows/deploy.yml", "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. ```yaml copy 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" ``` ### Beispiel für die Verwendung einer `job` Kontext-Workflow-Identität > \[!NOTE] > Die `job.workflow_*` Kontexteigenschaften sind auf GitHub Enterprise Server nicht verfügbar. Dieser beispielhafte wiederverwendbare Workflow verwendet `job.workflow_repository` und `job.workflow_sha`, um seinen eigenen Quellcode auszuchecken und nicht das Repository des Aufrufers. Dies ist nützlich, wenn ein wiederverwendbarer Arbeitsablauf auf Dateien zugreifen soll, die zusammen mit der Workflow-Definition gespeichert sind. ```yaml copy # In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml) name: Reusable deploy workflow on: workflow_call: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: repository: ${{ job.workflow_repository }} ref: ${{ job.workflow_sha }} - run: echo "Deploying from ${{ job.workflow_ref }}" - run: echo "Workflow file path is ${{ job.workflow_file_path }}" ``` ## 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](/de/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). | Eigenschaftsname | Typ | 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..result` | `string` | Das Ergebnis eines Arbeitsauftrags im wiederverwendbaren Workflow. Mögliche Werte sind `success`, `failure`, `cancelled` oder `skipped`. | | `jobs..outputs` | `object` | Der Ausgabensatz eines Auftrags in einem wiederverwendbaren Workflow. | | `jobs..outputs.` | `string` | Der Wert einer bestimmten Ausgabe für einen Job in einem wiederverwendbaren Workflow. | ### Beispielinhalt des `jobs`-Kontexts Dieses Kontextbeispiel `jobs` enthält das Ergebnis und der Ausgang einer Aufgabe aus einem wiederverwendbaren Workflow-Durchlauf. ```json { "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](/de/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). ```yaml copy 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`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid)-Wert verfügen und bereits ausgeführt wurden. | Eigenschaftsname | Typ | 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..outputs` | `object` | Der Satz an Ausgaben, die für diesen Schritt definiert wurden. Weitere Informationen finden Sie unter [Referenz zur Metadatensyntax](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#outputs-for-docker-container-and-javascript-actions). | | `steps..conclusion` | `string` | Ergebnis eines abgeschlossenen Schritts nach der Anwendung von [`continue-on-error`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-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..outcome` | `string` | Ergebnis eines abgeschlossenen Schritts vor der Anwendung von [`continue-on-error`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-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..outputs.` | `string` | Der Wert einer bestimmten Ausgabe | ### Beispielinhalt des `steps`-Kontexts In diesem `steps`-Beispielkontext siehst du zwei vorherige Schritte, die einen angegebenen [`id`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid)-Wert hatten. Der `id`-Wert des ersten Schritts lautete `checkout`, der des zweiten Schritts `generate_number`. Die Ausgabe des Schritts `generate_number` lautete `random_number`. ```json { "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. ```yaml copy 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. | Eigenschaftsname | Typ | 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 zum Verzeichnis mit vorinstallierten Tools für GitHub-gehostete Runner. Weitere Informationen finden Sie unter [Von GitHub gehostete Runner](/de/enterprise-server@3.22/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images). | | `runner.debug` | `string` | Dies ist nur festgelegt, wenn die [Debugprotokollierung](/de/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging) 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 aus einem von Linux GitHubgehosteten Runner. ```json { "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. ```yaml copy name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - 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 findest du unter [Verwenden von Geheimnissen in GitHub-Aktionen](/de/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). Das Geheimnis `GITHUB_TOKEN` wird automatisch für jeden Workflow-Lauf erstellt und ist immer im `secrets`-Kontext enthalten. Weitere Informationen finden Sie unter [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token). > \[!WARNING] > Wenn bei dem Workflowauftrag ein Geheimnis verwendet wurde, werden die in das Protokoll ausgegebenen Geheimnisse durch GitHub automatisch unkenntlich gemacht. Sie sollten die Geheimnisse nicht absichtlich in das Protokoll ausgeben. | Eigenschaftsname | Typ | 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 [Verwenden von GITHUB\_TOKEN für die Authentifizierung in Workflows](/de/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token). | | `secrets.` | `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. ```json { "github_token": "***", "NPM_TOKEN": "***", "SUPERSECRET": "***" } ``` ### Beispielverwendung des `secrets`-Kontexts In diesem Beispielworkflow wird die [GitHub CLI](/de/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli) verwendet, die das `GITHUB_TOKEN` als Wert für den `GH_TOKEN`-Eingabeparameter erfordert: ```yaml copy 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. | Eigenschaftsname | Typ | 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 finden Sie unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategyfail-fast). | | `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 Jobs 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](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymax-parallel). | ### 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`. ```json { "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. ```yaml copy 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. | Eigenschaftsname | Typ | 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.` | `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. ```json { "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. ```yaml copy 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@v7 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 dies keine implizit abhängigen Jobs umfasst (z. B. Jobs, die von einem anderen abhängigen Job abhängen). Weitere Informationen zum Definieren von Auftragsabhängigkeiten findest du unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds). | Eigenschaftsname | Typ | 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.` | `object` | Ein einzelner Job, von dem der aktuelle Job abhängt. | | `needs..outputs` | `object` | Die Menge der Ergebnisse von Jobs, von denen der aktuelle Job abhängt. | | `needs..outputs.` | `string` | Der Wert einer bestimmten Ausgabe für einen Job, von dem der aktuelle Job abhängt. | | `needs..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. ```json { "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. ```yaml copy 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](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows) eines wiederverwendbaren Workflows definiert. Die Eingabewerte werden von [`jobs..with`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) 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](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) eines Workflows definiert. Die Eigenschaften im `inputs`-Kontext werden in der Workflowdatei definiert. Sie sind nur in einem [wiederverwendbaren Workflow](/de/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)oder in einem durch das [Ereignis `workflow_dispatch`](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) ausgelösten Workflow verfügbar. | Eigenschaftsname | Typ | BESCHREIBUNG | | --------------------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `inputs` | `object` | Dieser Kontext ist nur in einem [wiederverwendbaren Workflow](/de/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) oder in einem Workflow, der von dem [`workflow_dispatch`-Ereignis](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) 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.` | | | | `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. ```json { "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. ```yaml copy 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. ```yaml copy 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 }}" ``` ## Weiterführende Lektüre * [Kontexte](/de/enterprise-server@3.22/actions/concepts/workflows-and-actions/contexts)