Referenz für Variablen

In 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.

Weitere Informationen zu Variablen finden Sie unter Variablen.

Standardumgebungsvariablen

Die von GitHub festgelegten Standardumgebungsvariablen sind in jedem Schritt eines Workflows verfügbar.

Da 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.

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 findest du unter Speichern von Informationen in Variablen und Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions).

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 Runnerumgebungen verwendet werden sollen.

Variable	BESCHREIBUNG
CI	Immer auf true festgelegt.
GITHUB_ACTION	Name der aktuell ausgeführten Aktion oder der id-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.
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	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.
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: https://api.github.com
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).
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: https://api.github.com/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 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).
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).
GITHUB_REF	Das vollständig geformte Ref des Branch- oder Tagnamens, der die Workflowausführung ausgelöst hat. Bei Workflows, die durch push ausgelöst wurden, ist dies das Branch- oder Tag-Ref, das gepusht wurde. 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 Head Branch. Bei Workflows, die von release ausgelöst werden, ist dies das erstellte Releasetag. Bei anderen Triggern handelt es sich um das Branch- oder Tag-Ref, das die Workflowausführung ausgelöst hat. Es wird nur festgelegt, wenn für den Ereignistyp ein Branch oder ein Tag verfügbar ist. Der angegebene Bezug ist vollständig formatiert, d. h. für Branches ist refs/heads/<branch_name> das Format. Für Pull-Request-Ereignisse, außer pull_request_target, die nicht zusammengeführt wurden, ist es refs/pull/<pr_number>/merge.

          `pull_request_target`-Ereignisse haben `ref` aus dem Basisbranch. Für Tags ist es `refs/tags/<tag_name>`. Beispiel: `refs/heads/feature-branch-1`. |

| 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 <pr_number>/merge. | | GITHUB_REF_PROTECTED | true wenn Verzweigungsschutz oder Rulesets 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. Ein Beispiel wäre 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. Ein Beispiel wäre 3. | | GITHUB_SERVER_URL| Die URL des GitHub-Servers Beispiel: https://github.com | | 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. 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). | | 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. 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 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. Ein Beispiel wäre Hosted Agent | | RUNNER_OS | Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind Linux, Windows oder macOS. Ein Beispiel wäre 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. Ein Beispiel wäre D:\a\_temp | | 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. Ein Beispiel wäre C:\hostedtoolcache\windows |

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 unten. Wenn Sie versuchen, den Wert einer dieser Standardvariablen zu überschreiben, wird diese Zuweisung ignoriert.

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.

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 256 KB 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 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).
• 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).
• Bis zu 100 Variablen auf Umgebungsebene.

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.

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 }}