GITHUB_TOKEN

Erfahren Sie, was GITHUB_TOKEN ist, wie es funktioniert und warum es für die sichere Automatisierung in GitHub Actions Workflows wichtig ist.

In diesem Artikel

Informationen zum GITHUB_TOKEN

Zu Beginn jedes Workflow-Jobs erstellt GitHub automatisch ein eindeutiges GITHUB_TOKEN Secret zur Verwendung in Ihrem Workflow. Sie können das GITHUB_TOKEN verwenden, um sich im Workflow-Job zu authentifizieren.

Wenn Sie GitHub Actions aktivieren, installiert GitHub ein GitHub App auf Ihrem Repository. Der GITHUB_TOKEN geheime Schlüssel ist ein GitHub App Installationszugriffstoken. Sie können das Installationszugriffstoken verwenden, um sich im Namen der auf deinem Repository installierten GitHub App zu authentifizieren. Die Berechtigungen des Tokens sind auf das Repository beschränkt, in dem sich der Workflow befindet. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Bevor jeder Job beginnt, ruft GitHub ein Installations-Zugriffstoken für den Job ab. Der GITHUB_TOKEN verfällt, wenn der Auftrag abgeschlossen ist oder nach Ablauf seiner effektiven maximalen Lebensdauer.

Die effektive maximale Lebensdauer des Tokens hängt vom Typ des Läufers ab:

  •           **              GitHub-gehostete Runner** Die maximale Ausführungszeit des Auftrags beträgt 6 Stunden, sodass `GITHUB_TOKEN` höchstens 6 Stunden lang bestehen kann.
  • Selbst gehostete Runner Die maximale Auftragsausführungszeit beträgt 5 Tage. Da es sich bei dem GITHUB_TOKEN jedoch um eine Installation access Token handelt, kann es nur bis zu 24 Stunden aktualisiert werden. Wenn Ihr Auftrag länger als 24 Stunden ausgeführt wird, verwenden Sie stattdessen eine personal access token oder andere Authentifizierungsmethode.

Das Token ist auch im kontext github.token verfügbar. Weitere Informationen finden Sie unter Kontextreferenz.

Wann GITHUB_TOKEN Workflowausführungen auslöst

Wenn Sie das GITHUB_TOKEN des Repositorys zum Ausführen von Aufgaben verwenden, lösen Ereignisse, die durch das GITHUB_TOKEN ausgelöst werden, mit den folgenden Ausnahmen keine neue Workflowausführung aus:

  • workflow_dispatch und repository_dispatch Ereignisse erstellen immer Workflow-Ausführungen.
  • pull_request-Ereignisse mit den Aktivitätstypen opened, synchronize oder reopened: Wenn ein Workflow, der GITHUB_TOKEN verwendet, einen Pull Request erstellt oder aktualisiert, führt das daraus resultierende pull_request-Ereignis zu Workflow-Ausführungen im Status Genehmigung erforderlich. Der Pull Request zeigt ein Banner im Merge-Feld an, und ein Benutzer mit Schreibzugriff auf das Repository kann die Durchläufe durch Auswahl von Workflows zur Ausführung genehmigen starten. Andere pull_request Aktivitätstypen (z. B. labeled, edited oder closed) lösen keine Workflow-Ausführungen aus. Dadurch wird verhindert, dass rekursive Workflows ausgeführt werden, während CI-Workflows weiterhin auf Pullanforderungen ausgeführt werden können, die von der Automatisierung erstellt wurden. Weitere Informationen zum Genehmigen von Workflows finden Sie unter Genehmigen von Workflowausführungen über Forks.

Bei allen anderen Ereignissen verhindert dieses Verhalten, dass Sie versehentlich rekursive Workflowausführungen erstellen. Wenn beispielsweise eine Workflowausführung Code über das GITHUB_TOKEN des Repositorys pusht, wird ein neuer Workflow auch dann nicht ausgeführt, wenn das Repository einen Workflow enthält, der für die Ausführung beim Auftreten von push-Ereignissen konfiguriert wurde.

Hinweis

Wenn Sie Workflowausführungen aus von Workflows erstellten Pull Requests ohne erforderliche Genehmigung ausführen möchten, verwenden Sie beim Erstellen oder Aktualisieren des Pull Requests ein GitHub App-Installationszugriffstoken oder ein personal access token anstelle von GITHUB_TOKEN.

Commits, die von einem GitHub Actions-Workflow gepusht werden, der das GITHUB_TOKEN verwendet, lösen keinen GitHub Pages-Build aus.

Nächste Schritte