GITHUB_TOKEN

Découvrez ce qu’est GITHUB_TOKEN, comment GITHUB_TOKEN fonctionne et pourquoi il est important pour l’automatisation sécurisée dans les flux de travail GitHub Actions.

Dans cet article

À propos de GITHUB_TOKEN

Au début de chaque tâche de workflow, GitHub crée automatiquement un secret unique GITHUB_TOKEN à utiliser dans le workflow. Vous pouvez utiliser GITHUB_TOKEN pour vous authentifier dans un travail de workflow.

Lorsque vous activez GitHub Actions, GitHub installe un GitHub App sur votre dépôt. Le GITHUB_TOKEN secret est un jeton d’accès GitHub App d’installation. Vous pouvez utiliser le jeton d’accès d’installation afin de vous authentifier au nom de GitHub App installé sur votre référentiel. Les autorisations du jeton sont limitées au dépôt qui contient votre workflow. Pour plus d’informations, consultez Syntaxe de flux de travail pour GitHub Actions.

Avant le début de chaque travail, GitHub récupère un jeton d’accès d’installation pour le travail. La GITHUB_TOKEN expire lorsque le travail se termine ou après sa durée de vie maximale effective.

La durée de vie maximale effective du jeton dépend du type de runner :

  • GitHub-runners hébergés La durée maximale d’exécution d’un job est de 6 heures, donc le GITHUB_TOKEN peut exister pendant 6 heures maximum.
  • Runners auto-hébergés La durée maximale d’exécution d’une tâche est de 5 jours. Toutefois, étant donné que le GITHUB_TOKEN est un jeton d'accès d'installation, il ne peut être actualisé que pendant 24 heures. Si votre tâche dure plus de 24 heures, utilisez plutôt un personal access token ou une autre méthode d’authentification.

Le jeton est également disponible dans le contexte github.token. Pour plus d’informations, consultez Référence des contextes.

Quand GITHUB_TOKEN déclenche l'exécution du flux de travail

Lorsque vous utilisez le GITHUB_TOKEN du dépôt pour effectuer des tâches, les événements déclenchés par le GITHUB_TOKEN ne créent pas de nouvelle exécution de workflow, à l’exception des cas suivants :

  • workflow_dispatch et repository_dispatch les événements créent toujours des exécutions de flux de travail.
  • pull_request événements avec les types d’activité opened, synchronize ou reopened : lorsqu’un flux de travail utilisant GITHUB_TOKEN crée ou met à jour une pull request, l’événement pull_request qui en résulte crée des exécutions de flux de travail à l’état approval-required. La pull request affiche une bannière dans l’encadré de fusion, et un utilisateur disposant d’un accès en écriture au dépôt peut lancer les exécutions en sélectionnant Approuver les workflows à exécuter. D’autres types d’activité pull_request (tels que labeled, editedou closed) ne créent pas d’exécutions de flux de travail. Cela empêche les exécutions récursives de workflows tout en permettant aux workflows d’intégration continue de s’exécuter sur des pull requests créées automatiquement. Pour plus d’informations sur l’approbation des exécutions de flux de travail, consultez Approbation d’exécutions de workflow à partir de duplications.

Pour tous les autres événements, ce comportement vous empêche de créer accidentellement des exécutions de flux de travail récursives. Par exemple, si une exécution de workflow pousse du code avec le GITHUB_TOKEN du dépôt, aucun nouveau workflow ne sera exécuté même quand le dépôt contient un workflow configuré pour s’exécuter quand des événements push se produisent.

Remarque

Si vous avez besoin que les exécutions de workflow issues de pull requests créées par un workflow s’exécutent sans nécessiter d’approbation, utilisez un jeton d’accès d’installation GitHub App ou un personal access token au lieu de GITHUB_TOKEN lors de la création ou de la mise à jour de la pull request.

Les commits envoyés par un workflow GitHub Actions qui utilise le GITHUB_TOKEN ne déclenchent pas de build GitHub Pages.

Étapes suivantes