{"meta":{"title":"Referenz für Variablen","intro":"Hier findest du Informationen zu unterstützten Variablen, Benennungskonventionen, Grenzwerten und Kontexten in GitHub Actions-Workflows.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/reference","title":"Verweis"},{"href":"/de/actions/reference/workflows-and-actions","title":"Workflows und Aktionen"},{"href":"/de/actions/reference/workflows-and-actions/variables","title":"Variablen"}],"documentType":"article"},"body":"# Referenz für Variablen\n\nHier findest du Informationen zu unterstützten Variablen, Benennungskonventionen, Grenzwerten und Kontexten in GitHub Actions-Workflows.\n\nIn diesem Artikel werden die unterstützten Variablen aufgeführt, die du in GitHub Actions-Workflows verwenden kannst, einschließlich Umgebungsvariablen, Konfigurationsvariablen und Standardvariablen, die von GitHub bereitgestellt werden. Verwende diese Referenz, um Variablennamen, Benennungskonventionen, Grenzwerte und unterstützte Kontexte beim Konfigurieren deines Workflows nachzuschlagen.\n\nWeitere Informationen zu Variablen finden Sie unter [Variablen](/de/actions/concepts/workflows-and-actions/variables).\n\n## Standardumgebungsvariablen\n\nDie von GitHub festgelegten Standardumgebungsvariablen sind in jedem Schritt eines Workflows verfügbar.\n\nDa Standardumgebungsvariablen von GitHub festgelegt und nicht in einem Workflow definiert sind, können Sie nicht über den `env` Kontext darauf zugreifen. Die meisten Standardvariablen verfügen über eine entsprechende Kontexteigenschaft mit einem ähnlichen Namen. So kann beispielsweise der Wert der Variable `GITHUB_REF` während der Workflowverarbeitung mit der Kontexteigenschaft `${{ github.ref }}` gelesen werden.\n\nDu kannst den Wert der Standardumgebungsvariablen namens `GITHUB_*` und `RUNNER_*` nicht überschreiben. Derzeit kannst du den Wert der Variablen `CI` überschreiben. Es ist jedoch nicht garantiert, dass dies immer möglich sein wird. Weitere Informationen zum Festlegen von Umgebungsvariablen findest du unter [Speichern von Informationen in Variablen](/de/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-environment-variables-for-a-single-workflow) und [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable).\n\nEs wird dringend empfohlen, die Aktionen mithilfe von Variablen auf das Dateisystem zugreifen zu lassen statt über hartkodierte Dateipfade. GitHub legt Variablen für Aktionen fest, die in allen Runnerumgebungen verwendet werden sollen.\n\n| Variable | BESCHREIBUNG |\n| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `CI` | Immer auf `true` festgelegt. |\n| `GITHUB_ACTION` | Name der aktuell ausgeführten Aktion oder der [`id`](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid)-Wert eines Schritts. Ein Beispiel für eine Aktion wäre: `__repo-owner_name-of-action-repo`.
GitHub entfernt Sonderzeichen und verwendet den Namen `__run`, wenn der aktuelle Schritt ein Skript ohne `id` ausführt. Wenn Sie ein Skript oder eine Aktion in einem Auftrag mehrmals verwenden, enthält der Name ein Suffix, das aus einem Unterstrich, gefolgt von einer laufenden Nummer, besteht. So lautet z. B. der Name des ersten Skripts, das Sie ausführen, `__run` und der des zweiten `__run_2`. Analog dazu erhält der zweite Aufruf von `actions/checkout` den Namen `actionscheckout2`. |\n| `GITHUB_ACTION_PATH` | Der Pfad, wo sich eine Aktion befindet. Diese Eigenschaft wird nur in Kompositaktionen unterstützt. Sie können diesen Pfad verwenden, um in das Verzeichnis zu wechseln, in dem sich die Aktion befindet, und um auf andere Dateien in demselben Repository zuzugreifen. Beispiel: `/home/runner/work/_actions/repo-owner/name-of-action-repo/v1`. |\n| `GITHUB_ACTION_REPOSITORY` | 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`. |\n| `GITHUB_ACTIONS` | Wenn GitHub Actions den Workflow ausführt, ist der Wert dieser Variable immer auf `true` festgelegt. Sie können diese Variable verwenden, um zu differenzieren, wann Tests lokal oder von GitHub Actions durchgeführt werden. |\n| `GITHUB_ACTOR` | Name der Person oder App, die den Workflow initiiert hat. Beispiel: `octocat`. |\n| `GITHUB_ACTOR_ID` | 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. |\n| `GITHUB_API_URL` | Gibt die API-URL zurück. Beispiel: `https://api.github.com` |\n| `GITHUB_BASE_REF` | Name des Basisverweises oder Zielbranchs des Pull Requests in einer Workflowausführung. Diese Variable wird nur festgelegt, wenn das Ereignis, durch das eine Workflowausführung ausgelöst wird, entweder `pull_request` oder `pull_request_target` ist. Beispiel: `main`. |\n| `GITHUB_ENV` | Der Pfad auf dem Runner zu der Datei, in der die Variablen aus Workflowbefehlen festgelegt sind. Der Pfad zu dieser Datei ist einzigartig für den aktuellen Schritt und ändert sich bei jedem Schritt in einem Auftrag. Beispiel: `/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a`. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable). |\n| `GITHUB_EVENT_NAME` | Der Name des Ereignisses, das den Workflow ausgelöst hat. Beispiel: `workflow_dispatch`. |\n| `GITHUB_EVENT_PATH` | Pfad des Runners zur Datei mit der vollständigen Webhooknutzlast des Ereignisses. Beispiel: `/github/workflow/event.json`. |\n| `GITHUB_GRAPHQL_URL` | Gibt die GraphQL-API-URL zurück. Beispiel: `https://api.github.com/graphql` |\n| `GITHUB_HEAD_REF` | Der Verweis auf den Hauptbranch oder der Quellbranch des Pull Requests in einer Workflowausführung. Diese Eigenschaft wird nur festgelegt, wenn das Ereignis, durch das eine Workflowausführung ausgelöst wird, entweder `pull_request` oder `pull_request_target` ist. Beispiel: `feature-branch-1`. |\n| `GITHUB_JOB` | Die [job\\_id](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_id) des aktuellen Auftrags. Beispiel: `greeting_job`. |\n| `GITHUB_OUTPUT` | Pfad auf dem Runner zu der Datei, in der die Ausgaben des aktuellen Schritts aus Workflowbefehlen festgelegt sind. Der Pfad zu dieser Datei ist einzigartig für den aktuellen Schritt und ändert sich bei jedem Schritt in einem Auftrag. Beispiel: `/home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0`. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter). |\n| `GITHUB_PATH` | Pfad auf dem Runner zu der Datei, in der die `PATH`-Systemvariablen aus Workflowbefehlen festgelegt sind. Der Pfad zu dieser Datei ist einzigartig für den aktuellen Schritt und ändert sich bei jedem Schritt in einem Auftrag. Beispiel: `/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5`. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path). |\n| `GITHUB_REF` | 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`. |\n| `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 [Informationen zu Pull Requests](/de/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). | |\n| `GITHUB_REF_NAME` | 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`. |\n| `GITHUB_REF_PROTECTED` | `true` wenn Verzweigungsschutz oder [Rulesets](/de/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository) für den Verweis konfiguriert sind, der die Workflow-Ausführung ausgelöst hat. |\n| `GITHUB_REF_TYPE` | Der Typ des Verweises, der die Workflowausführung ausgelöst hat. Gültige Werte sind `branch` und `tag`. |\n| `GITHUB_REPOSITORY` | Name des Eigentümers und des Repositorys. Beispiel: `octocat/Hello-World`. |\n| `GITHUB_REPOSITORY_ID` | Die ID des Repositorys. Beispiel: `123456789`. Beachte, dass sie sich vom Repositorynamen unterscheidet. |\n| `GITHUB_REPOSITORY_OWNER` | Name des Repositorybesitzers. Beispiel: `octocat`. |\n| `GITHUB_REPOSITORY_OWNER_ID` | Die Konto-ID des Repositorybesitzers bzw. der Repositorybesitzerin. Beispiel: `1234567`. Beachte, dass sie sich vom Besitzernamen unterscheidet. |\n| `GITHUB_RETENTION_DAYS` | Anzahl der Tage, für die Protokolle und Artefakte der Workflowausführung beibehalten werden. Beispiel: `90`. |\n| `GITHUB_RUN_ATTEMPT` | 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. Beispiel: `3`. |\n| `GITHUB_RUN_ID` | 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. Ein Beispiel wäre `1658821493`. |\n| `GITHUB_RUN_NUMBER` | 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. Ein Beispiel wäre `3`. |\n| `GITHUB_SERVER_URL` | Die URL des GitHub-Servers Beispiel: `https://github.com` |\n| `GITHUB_SHA` | 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/actions/using-workflows/events-that-trigger-workflows). Beispiel: `ffac537e6cbbf934b08745a378932722df287a53`. |\n| `GITHUB_STEP_SUMMARY` | Der Pfad im Runner zur Datei, die Auftragszusammenfassungen von Workflowbefehlen enthält. Der Pfad zu dieser Datei ist einzigartig für den aktuellen Schritt und ändert sich bei jedem Schritt in einem Auftrag. Beispiel: `/home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c`. Weitere Informationen finden Sie unter [Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)](/de/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary). |\n| `GITHUB_TRIGGERING_ACTOR` | 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. |\n| `GITHUB_WORKFLOW` | Der Name des Workflows. Beispiel: `My test workflow`. Wird in der Workflowdatei kein Wert für `name` festgelegt, entspricht der Wert dieser Variable dem vollständigen Pfad der Workflowdatei im Repository. |\n| `GITHUB_WORKFLOW_REF` | Der Verweispfad zum Workflow. Beispiel: `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`. |\n| `GITHUB_WORKFLOW_SHA` | Der Commit-SHA für die Workflowdatei. |\n| `GITHUB_WORKSPACE` | Standardarbeitsverzeichnis des Runners für die Schritte und Standardspeicherort deines Repositorys bei Verwendung der Aktion [`checkout`](https://github.com/actions/checkout). Beispiel: `/home/runner/work/my-repo-name/my-repo-name`. |\n| `RUNNER_ARCH` | Die Architektur des Runners, der den Auftrag ausführt. Mögliche Werte sind `X86`, `X64`, `ARM` oder `ARM64`. |\n| `RUNNER_DEBUG` | Dies ist nur festgelegt, wenn die [Debugprotokollierung](/de/actions/monitoring-and-troubleshooting-workflows/enabling-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. |\n| `RUNNER_ENVIRONMENT` | 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. |\n| `RUNNER_NAME` | 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. Ein Beispiel wäre `Hosted Agent` |\n| `RUNNER_OS` | Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind `Linux`, `Windows` oder `macOS`. Ein Beispiel wäre `Windows` |\n| `RUNNER_TEMP` | 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. Ein Beispiel wäre `D:\\a\\_temp` |\n| `RUNNER_TOOL_CACHE` | Der Pfad zu dem Verzeichnis, das vorinstallierte Tools für von GitHub gehostete Runner enthält. Weitere Informationen finden Sie unter [Von GitHub gehostete Runner](/de/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software). Ein Beispiel wäre `C:\\hostedtoolcache\\windows` |\n\n> \\[!NOTE]\n> Wenn du die URL einer Workflowausführung in einem Auftrag verwenden musst, kannst du diese Variablen kombinieren: `$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID`.\n\n## Benennungskonventionen für Konfigurationsvariablen\n\nFür Namen von Konfigurationsvariablen gelten folgende Regeln:\n\n* Darf nur alphanumerische Zeichen (`[a-z]`, `[A-Z]`, `[0-9]`) oder Unterstriche (`_`) enthalten Leerzeichen sind nicht zulässig.\n* darf nicht mit dem `GITHUB_`-Präfix beginnen.\n* darf nicht mit einer Zahl beginnen.\n* Bei Verweisen wird die Groß-/Kleinschreibung nicht beachtet. GitHub speichert Geheimnisnamen unabhängig davon, wie sie eingegeben werden.\n* Müssen für das Repository, die Organisation oder das Unternehmen eindeutig sein, in dem bzw. der sie erstellt werden\n\n## Namens-Konventionen für Umgebungsvariablen\n\nWenn Sie eine Umgebungsvariable festlegen, dürfen Sie nicht die Namen von Standardumgebungsvariablen verwenden. Eine vollständige Liste der Standardumgebungsvariablen findest du unter [Referenz für Variablen](/de/actions/reference/variables-reference#default-environment-variables) unten. Wenn Sie versuchen, den Wert einer dieser Standardvariablen zu überschreiben, wird diese Zuweisung ignoriert.\n\n> \\[!NOTE]\n> Du kannst alle für einen Workflowschritt verfügbaren Umgebungsvariablen auflisten, indem du in einem Schritt `run: env` verwendest und dann die Ausgabe für diesen Schritt untersuchst.\n\n## Rangfolge der Konfigurationsvariablen\n\nWenn eine Variable mit demselben Namen auf mehreren Ebenen vorhanden ist, erhält die Variable auf der niedrigsten Ebene Vorrang. Wenn beispielsweise eine Variable auf Organisationsebene denselben Namen wie eine Variable auf Repositoryebene aufweist, erhält die Variable auf Repositoryebene Vorrang. Analog dazu hat bei einer Variable mit demselben Namen in einer Organisation, einem Repository und einer Umgebung die Variable auf Umgebungsebene Vorrang.\n\n> \\[!NOTE]\n> Variablen auf Umgebungsebene sind auf dem Runner erst nach Beginn der Auftragsausführung verfügbar. Dies bedeutet, dass Variablen auf Umgebungsebene keine Variablen in den `env` Und `vars` Kontexten überschreiben.\n\nFür wiederverwendbare Workflows werden die Variablen aus dem Repository des Aufrufers verwendet. Variablen aus dem Repository, das den aufgerufenen Workflow enthält, werden dem Aufruferworkflow nicht zur Verfügung gestellt.\n\n## Grenzwerte für Konfigurationsvariablen\n\nVariablen sind auf eine Größe von je 48 KB begrenzt.\n\nSie können bis zu 1.000 Organisationsvariablen, bis zu 500 Variablen pro Repository und bis zu 100 Variablen pro Umgebung speichern. Die kombinierte Gesamtgröße für Organisations- und Repositoryvariablen ist auf 256 KB pro Workflowausführung begrenzt.\n\nEin Workflow, der in einem Repository erstellt wurde, kann auf die folgende Anzahl von Variablen zugreifen:\n\n* Bis zu 500 Repositoryvariablen, wenn die Gesamtgröße der Repositoryvariablen kleiner als 256 KB ist. Wenn die Gesamtgröße der Repositoryvariablen 256 KB überschreitet, sind nur die Repositoryvariablen verfügbar, die unter den Grenzwert fallen (alphabetisch sortiert nach Variablennamen).\n* Bis zu 1.000 Organisationsvariablen, wenn die Gesamtgröße der Repository- und Organisationsvariablen kleiner als 256 KB ist. Wenn die Gesamtgröße der Organisations- und Repositoryvariablen 256 KB überschreitet, sind nur die Organisationsvariablen verfügbar, die unter diesen Grenzwert fallen (nach Berücksichtigung der Repositoryvariablen und alphabetisch sortiert nach Variablennamen).\n* Bis zu 100 Variablen auf Umgebungsebene.\n\n> \\[!NOTE]\n> Variablen auf Umgebungsebene werden nicht auf das Limit für die Gesamtgröße von 256 KB angerechnet. Wenn Sie das kombinierte Größenlimit für Repository- und Organisationsvariablen überschreiten und dennoch zusätzliche Variablen benötigen, können Sie eine Umgebung verwenden und zusätzliche Variablen in der Umgebung definieren.\n\n## Unterstützte Kontexte\n\nOft werden Sie entweder den Kontext `env` oder `github` verwenden, um auf Werte von Variablen in Teilen des Workflows zuzugreifen, die verarbeitet werden, bevor Aufträge an Runner gesendet werden.\n\n> \\[!WARNING] Gib den `github`-Kontext nicht in Protokollen aus. Sie enthalten vertrauliche Informationen.\n\n| Kontext | Anwendungsfall | Beispiel |\n| -------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |\n| `env` | Verweisen auf benutzerdefinierte Variablen, die im Workflow definiert sind | `${{ env.MY_VARIABLE }}` |\n| `github` | Verweisen auf Informationen zur Workflowausführung und zu dem Ereignis, durch das die Ausführung ausgelöst wurde | `${{ github.repository }}` |"}