# Referenz für Variablen
Hier finden Sie Informationen zu unterstützten Variablen, Benennungskonventionen, Grenzwerten und Kontexten in GitHub Actions Workflows.
In diesem Artikel werden die unterstützten Variablen aufgeführt, die Sie in GitHub Actions Workflows verwenden können, einschließlich Umgebungsvariablen, Konfigurationsvariablen und Standardvariablen, die von GitHub. Verwende diese Referenz, um Variablennamen, Benennungskonventionen, Grenzwerte und unterstützte Kontexte beim Konfigurieren deines Workflows nachzuschlagen.
Weitere Informationen zu Variablen finden Sie unter [Variablen](/de/enterprise-server@3.22/actions/concepts/workflows-and-actions/variables).
## Standardumgebungsvariablen
Die Standardumgebungsvariablen, die GitHub für jeden Schritt in einem Workflow festgelegt werden.
Da Standardumgebungsvariablen in einem Workflow festgelegt GitHub und nicht definiert sind, können sie nicht über den `env` Kontext zugegriffen werden. Die meisten Standardvariablen verfügen über eine entsprechende Kontexteigenschaft mit einem ähnlichen Namen. Beispielsweise kann der Wert der Variablen während der Workflowverarbeitung mithilfe der `GITHUB_REF``${{ github.ref }}` Kontexteigenschaft gelesen werden.
Du 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 finden Sie unter [Speichern von Informationen in Variablen](/de/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-environment-variables-for-a-single-workflow) und [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).
Es 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 Läuferumgebungen verwendet werden sollen.
| Variable | BESCHREIBUNG |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CI` | Immer auf `true` festgelegt. |
| `GITHUB_ACTION` | 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. Ein Beispiel für eine Aktion wäre: `__repo-owner_name-of-action-repo`.
|
| GitHub entfernt Sonderzeichen und setzt den Namen `__run` ein, wenn der aktuelle Schritt ein Skript ohne ein `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`. | |
| `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`. |
| `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`. |
| `GITHUB_ACTIONS` | Legen Sie immer fest, `true` wann GitHub Actions der Workflow ausgeführt wird. Sie können diese Variable verwenden, um zu unterscheiden, wann Tests lokal oder nach GitHub Actions. |
| `GITHUB_ACTOR` | Name der Person oder App, die den Workflow initiiert hat. Beispiel: `octocat`. |
| `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. |
| `GITHUB_API_URL` | Gibt die API-URL zurück. Beispiel: `http(s)://HOSTNAME/api/v3` |
| `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`. |
| `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/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable). |
| `GITHUB_EVENT_NAME` | Der Name des Ereignisses, das den Workflow ausgelöst hat. Beispiel: `workflow_dispatch`. |
| `GITHUB_EVENT_PATH` | Pfad des Runners zur Datei mit der vollständigen Webhooknutzlast des Ereignisses. Beispiel: `/github/workflow/event.json`. |
| `GITHUB_GRAPHQL_URL` | Gibt die GraphQL-API-URL zurück. Beispiel: `http(s)://HOSTNAME/api/graphql` |
| `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`. |
| `GITHUB_JOB` | Die [job\_id](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_id) des aktuellen Auftrags. Beispiel: `greeting_job`. |
| `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/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-output-parameter). |
| `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/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path). |
| `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`. |
| `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` | 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` | `true` wenn Verzweigungsschutz für den Verweis konfiguriert sind, der die Workflow-Ausführung ausgelöst hat. |
| `GITHUB_REF_TYPE` | Der Typ des Verweises, der die Workflowausführung ausgelöst hat. Gültige Werte sind `branch` und `tag`. |
| `GITHUB_REPOSITORY` | Name des Eigentümers und des Repositorys. Beispiel: `octocat/Hello-World`. |
| `GITHUB_REPOSITORY_ID` | Die ID des Repositorys. Beispiel: `123456789`. Beachte, dass sie sich vom Repositorynamen unterscheidet. |
| `GITHUB_REPOSITORY_OWNER` | Name des Repositorybesitzers. Beispiel: `octocat`. |
| `GITHUB_REPOSITORY_OWNER_ID` | Die Konto-ID des Repositorybesitzers bzw. der Repositorybesitzerin. Beispiel: `1234567`. Beachte, dass sie sich vom Besitzernamen unterscheidet. |
| `GITHUB_RETENTION_DAYS` | Anzahl der Tage, für die Protokolle und Artefakte der Workflowausführung beibehalten werden. Beispiel: `90`. |
| `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`. |
| `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. Beispiel: `1658821493`. | |
| `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. Beispiel: `3`. | |
| `GITHUB_SERVER_URL` | Die URL des GitHub Servers. Beispiel: `https://HOSTNAME` |
| `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/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). Beispiel: `ffac537e6cbbf934b08745a378932722df287a53`. |
| `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/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-job-summary). |
| `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. |
| `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. |
| `GITHUB_WORKFLOW_REF` | Der Verweispfad zum Workflow. Beispiel: `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`. |
| `GITHUB_WORKFLOW_SHA` | Der Commit-SHA für die Workflowdatei. |
| `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`. |
| `RUNNER_ARCH` | Die Architektur des Runners, der den Auftrag ausführt. Mögliche Werte sind `X86`, `X64`, `ARM` oder `ARM64`. |
| `RUNNER_DEBUG` | 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` | 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. |
| `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. Zum Beispiel `Hosted Agent` | |
| `RUNNER_OS` | |
| Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind `Linux`, `Windows` oder `macOS`. Zum Beispiel `Windows` | |
| `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. Zum Beispiel `D:\a\_temp` | |
| `RUNNER_TOOL_CACHE` | |
| 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). Zum Beispiel `C:\hostedtoolcache\windows` | |
> \[!NOTE]
> 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`.
## Benennungskonventionen für Konfigurationsvariablen
Für Namen von Konfigurationsvariablen gelten folgende Regeln:
* Darf nur alphanumerische Zeichen (`[a-z]`, `[A-Z]`, `[0-9]`) oder Unterstriche (`_`) enthalten Leerzeichen sind nicht zulässig.
* darf nicht mit dem `GITHUB_`-Präfix beginnen.
* darf nicht mit einer Zahl beginnen.
* Bei Verweisen wird die Groß-/Kleinschreibung nicht beachtet. GitHub speichert Geheimnisnamen unabhängig davon, wie sie eingegeben werden.
* Müssen für das Repository, die Organisation oder das Unternehmen eindeutig sein, in dem bzw. der sie erstellt werden
## Namens-Konventionen für Umgebungsvariablen
Wenn 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/enterprise-server@3.22/actions/reference/workflows-and-actions/variables#default-environment-variables) unten. Wenn Sie versuchen, den Wert einer dieser Standardvariablen zu überschreiben, wird diese Zuweisung ignoriert.
> \[!NOTE]
> 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.
## Rangfolge der Konfigurationsvariablen
Wenn 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.
> \[!NOTE]
> 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.
Fü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.
## Grenzwerte für Konfigurationsvariablen
Variablen sind auf eine Größe von je 48 KB begrenzt.
Sie 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 10 MB pro Workflowausführung begrenzt.
Ein Workflow, der in einem Repository erstellt wurde, kann auf die folgende Anzahl von Variablen zugreifen:
* Bis zu 500 Repositoryvariablen, wenn die Gesamtgröße der Repositoryvariablen weniger als 10 MB beträgt. Wenn die Gesamtgröße der Repositoryvariablen 10 MB überschreitet, sind nur die Repositoryvariablen verfügbar, die unter dem Grenzwert liegen (alphabetisch sortiert nach Variablennamen).
* Bis zu 1.000 Organisationsvariablen, wenn die Gesamtgröße der Repository- und Organisationsvariablen weniger als 10 MB beträgt. Wenn die kombinierte Gesamtgröße der Organisations- und Repositoryvariablen 10 MB übersteigt, sind nur die Organisationsvariablen verfügbar, die unter diesem Grenzwert liegen (nach Berücksichtigung der Repositoryvariablen und alphabetisch nach Variablennamen sortiert).
* Bis zu 100 Variablen auf Umgebungsebene.
> \[!NOTE]
> Variablen auf Umgebungsebene werden nicht auf das Limit für die Gesamtgröße von 10 MB 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.
## Unterstützte Kontexte
Oft 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.
> \[!WARNING] Gib den `github`-Kontext nicht in Protokollen aus. Sie enthalten vertrauliche Informationen.
| Kontext | Anwendungsfall | Beispiel |
| -------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| `env` | Verweisen auf benutzerdefinierte Variablen, die im Workflow definiert sind | `${{ env.MY_VARIABLE }}` |
| `github` | Verweisen auf Informationen zur Workflowausführung und zu dem Ereignis, durch das die Ausführung ausgelöst wurde | `${{ github.repository }}` |