Cet article répertorie les variables prises en charge que vous pouvez utiliser dans les flux de travail GitHub Actions, notamment les variables d’environnement, les variables de configuration et les variables par défaut fournies par GitHub. Utilisez cette référence pour rechercher des noms de variables, des conventions de nommage, des limites et des contextes pris en charge lors de la configuration de vos flux de travail.
Pour plus d’informations sur les variables, consultez Variables.
Variables d’environnement par défaut
Les variables d’environnement par défaut que GitHub définit sont disponibles pour chaque étape d’un workflow.
Étant donné que les variables d’environnement par défaut sont définies par GitHub et non dans un flux de travail, elles ne sont pas accessibles via le contexte env
. Cependant, la plupart des variables par défaut ont une propriété de contexte correspondante et portant un nom similaire. Par exemple, la valeur de la variable GITHUB_REF
peut être lue pendant le traitement du workflow à l’aide de la propriété de contexte ${{ github.ref }}
.
Vous ne pouvez pas remplacer la valeur des variables d’environnement par défaut appelées GITHUB_*
et RUNNER_*
. Actuellement, vous pouvez remplacer la valeur de la variable CI
. Toutefois, il n’est pas garanti que cela sera toujours possible. Pour plus d'informations sur la définition des variables d'environnement, consultez Stocker des informations dans des variables et Workflow commands for GitHub Actions.
Nous recommandons vivement que les actions utilisent des variables pour accéder au système de fichiers plutôt que des chemins de fichier codés en dur. GitHub définit les variables pour les actions à utiliser dans tous les environnements d’exécution.
Variable | Description |
---|---|
CI | Toujours défini sur true . |
GITHUB_ACTION | Nom de l’action en cours d’exécution ou id d’une étape. Par exemple, pour une action, __repo-owner_name-of-action-repo .GitHub supprime les caractères spéciaux et utilise le nom __run quand l’étape actuelle exécute un script sans id . Si vous utilisez le même script ou la même action plusieurs fois dans un même travail, le nom inclut un suffixe qui se compose du numéro de séquence précédé d’un trait de soulignement. Par exemple, le premier script que vous exécutez aura le nom __run et le deuxième script sera nommé __run_2 . De même, le deuxième appel de actions/checkout sera actionscheckout2 . |
GITHUB_ACTION_PATH | Chemin où figure une action. Cette propriété est prise en charge uniquement dans les actions composites. Vous pouvez utiliser ce chemin d'accès pour modifier les annuaires dans lesquels se trouve l'action et accéder à d'autres fichiers dans le même référentiel. Par exemple : /home/runner/work/_actions/repo-owner/name-of-action-repo/v1 . |
GITHUB_ACTION_REPOSITORY | Pour une étape exécutant une action, il s’agit du propriétaire et du nom du dépôt de l’action. Par exemple : actions/checkout . |
GITHUB_ACTIONS | Toujours définie sur true quand GitHub Actions exécute le workflow. Vous pouvez utiliser cette variable pour différencier quand les tests sont exécutés localement ou par GitHub Actions. |
GITHUB_ACTOR | Nom de la personne ou de l’application qui a lancé le workflow. Par exemple : octocat . |
GITHUB_ACTOR_ID | ID de compte de la personne ou de l’application qui a déclenché l’exécution initiale du workflow. Par exemple : 1234567 . Notez qu’il diffère du nom d’utilisateur de l’acteur. |
GITHUB_API_URL | Retourne l’URL de l’API. Par exemple : https://api.github.com . |
GITHUB_BASE_REF | Nom de la référence de base ou de la branche cible de la demande de tirage (pull request) dans une exécution de workflow. Il est défini uniquement lorsque l’événement qui déclenche une exécution de workflow est pull_request ou pull_request_target . Par exemple : main . |
GITHUB_ENV | Chemin sur l’exécuteur jusqu’au fichier qui définit les variables à partir des commandes de workflow. Le chemin d’accès à ce fichier est unique pour l’étape en cours et change pour chaque étape d’une tâche. Par exemple : /home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a . Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». |
GITHUB_EVENT_NAME | Nom de l’événement qui a déclenché le workflow. Par exemple : workflow_dispatch . |
GITHUB_EVENT_PATH | Chemin jusqu’au fichier sur l’exécuteur qui contient la charge utile de webhook d’événement complet. Par exemple : /github/workflow/event.json . |
GITHUB_GRAPHQL_URL | Retourne l’URL de l’API GraphQL. Par exemple : https://api.github.com/graphql . |
GITHUB_HEAD_REF | Référence principale ou branche source de la demande de tirage (pull request) dans une exécution de workflow. Cette propriété est définie uniquement quand l’événement qui déclenche une exécution de workflow est pull_request ou pull_request_target . Par exemple : feature-branch-1 . |
GITHUB_JOB | Élément job_id du travail actuel. Par exemple : greeting_job . |
GITHUB_OUTPUT | Chemin d’accès de l’exécuteur jusqu’au fichier qui définit les productions de l’étape en cours à partir des commandes de workflow. Le chemin d’accès à ce fichier est unique pour l’étape en cours et change pour chaque étape d’une tâche. Par exemple : /home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 . Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». |
GITHUB_PATH | Chemin sur l’exécuteur jusqu’au fichier qui définit les variables PATH système à partir des commandes de workflow. Le chemin d’accès à ce fichier est unique pour l’étape en cours et change pour chaque étape d’une tâche. Par exemple : /home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 . Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». |
GITHUB_REF | Référence complète de la branche ou de l’étiquette qui a déclenché l’exécution du workflow. Pour les workflows déclenchés par push , il s’agit de la branche ou de la référence d’étiquette qui a été envoyée. Pour les workflows déclenchés par pull_request , il s’agit de la branche de fusion de la requête de tirage. Pour les workflows déclenchés par release , il s’agit de l’étiquette de mise en production créée. Pour les autres déclencheurs, il s’agit de la branche ou de la référence d’étiquette qui a déclenché l’exécution du workflow. Cette variable est définie uniquement si une branche ou une étiquette est disponible pour le type d’événement. La référence donnée est entièrement formée, ce qui signifie que pour les branches, le format est refs/heads/<branch_name> . Pour les événements de demande de tirage (pull request), à l’exception de pull_request_target , le format est refs/pull/<pr_number>/merge . Les événements pull_request_target ont le ref de la branche de base. Pour les balises, le format est refs/tags/<tag_name> . Par exemple : refs/heads/feature-branch-1 . |
GITHUB_REF_NAME | Nom de référence court de la branche ou de l’étiquette qui a déclenché l’exécution du workflow. Cette valeur correspond au nom de la branche ou de l’étiquette indiquée sur GitHub. Par exemple : feature-branch-1 .Pour les demandes de tirage, le format est <pr_number>/merge . |
GITHUB_REF_PROTECTED | true si les protections de branche ou les ensembles de règles sont configurés pour la référence qui a déclenché l’exécution du flux de travail. |
GITHUB_REF_TYPE | Type de référence qui a déclenché l’exécution du workflow. Les valeurs valides sont branch ou tag . |
GITHUB_REPOSITORY | Nom du propriétaire et du dépôt. Par exemple : octocat/Hello-World . |
GITHUB_REPOSITORY_ID | ID du dépôt. Par exemple : 123456789 . Notez qu’il diffère du nom du dépôt. |
GITHUB_REPOSITORY_OWNER | Nom du propriétaire du référentiel. Par exemple : octocat . |
GITHUB_REPOSITORY_OWNER_ID | ID de compte du propriétaire du dépôt. Par exemple : 1234567 . Notez qu’il diffère du nom du propriétaire. |
GITHUB_RETENTION_DAYS | Nombre de jours pendant lesquels les journaux et artefacts d’exécution de workflow sont conservés. Par exemple : 90 . |
GITHUB_RUN_ATTEMPT | Numéro unique pour chaque tentative d’exécution d’un workflow particulier dans un dépôt. Ce numéro commence à 1 pour la première tentative d’exécution du workflow et augmente d’une unité à chaque nouvelle exécution. Par exemple : 3 . |
GITHUB_RUN_ID | Numéro unique pour chaque exécution de workflow dans un dépôt. Ce numéro ne change pas si vous réexécutez l’exécution de workflow. Par exemple, 1658821493 . |
GITHUB_RUN_NUMBER | Numéro unique de chaque exécution d’un workflow particulier dans un dépôt. Ce nombre commence à 1 pour la première exécution du workflow et s’incrémente à chaque nouvelle exécution. Ce numéro ne change pas si vous réexécutez l’exécution de workflow. Par exemple, 3 . |
GITHUB_SERVER_URL | L’URL du serveur GitHub. Par exemple : https://github.com . |
GITHUB_SHA | SHA de commit qui a déclenché le workflow. La valeur de ce SHA de commit dépend de l’événement qui a déclenché le workflow. Pour plus d’informations, consultez « Événements qui déclenchent des flux de travail ». Par exemple : ffac537e6cbbf934b08745a378932722df287a53 . |
GITHUB_STEP_SUMMARY | Le chemin d’accès de l’exécuteur permettant d’accéder au fichier qui contient les résumés des tâches des commandes de flux de travail. Le chemin d’accès à ce fichier est unique pour l’étape en cours et change pour chaque étape d’une tâche. Par exemple : /home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c . Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». |
GITHUB_TRIGGERING_ACTOR | Nom d’utilisateur de l’utilisateur ayant lancé l’exécution du workflow. Si l’exécution du workflow est une réexécution, cette valeur peut être différente de github.actor . Toutes les réexécutions de workflow utilisent les privilèges de github.actor , même si l’acteur qui initie la réexécution (github.triggering_actor ) a des privilèges différents. |
GITHUB_WORKFLOW | Nom du workflow. Par exemple : My test workflow . Si le fichier de workflow ne spécifie pas un name , la valeur de cette variable est le chemin complet du fichier de workflow dans le dépôt. |
GITHUB_WORKFLOW_REF | Chemin de référence du workflow. Par exemple : octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch . |
GITHUB_WORKFLOW_SHA | SHA de commit pour le fichier de workflow. |
GITHUB_WORKSPACE | Le répertoire de travail par défaut sur l’exécuteur pour les étapes et l’emplacement par défaut de votre référentiel pendant l’utilisation de l’action checkout . Par exemple : /home/runner/work/my-repo-name/my-repo-name . |
RUNNER_ARCH | Architecture de l’exécuteur qui exécute le travail. Les valeurs possibles sont X86 , X64 , ARM ou ARM64 . |
RUNNER_DEBUG | Cela est défini seulement si la journalisation du débogage est activée et a toujours la valeur 1 . À titre indicatif, il peut être utile d’activer un débogage supplémentaire ou une journalisation détaillée dans vos propres étapes de travail. |
RUNNER_ENVIRONMENT | L’environnement de l’exécuteur de la tâche. Les valeurs possibles sont les suivantes : github-hosted pour les exécuteurs hébergés par GitHub fournis par GitHub et self-hosted pour les exécuteurs auto-hébergés configurés par le propriétaire du référentiel. |
RUNNER_NAME | Nom de l’exécuteur du travail. Ce nom peut ne pas être unique dans l’exécution d’un flux de travail, car les exécutants au niveau du référentiel et de l'organisation peuvent utiliser le même nom. Par exemple, Hosted Agent |
RUNNER_OS | Système d’exploitation de l’exécuteur du travail. Les valeurs possibles sont Linux , Windows ou macOS . Par exemple, Windows |
RUNNER_TEMP | Chemin d’un répertoire temporaire sur l’exécuteur. Ce répertoire est vidé au début et à la fin de chaque travail. Notez que les fichiers ne sont pas supprimés si le compte d’utilisateur de l’exécuteur n’a pas l’autorisation de les supprimer. Par exemple, D:\a\_temp |
RUNNER_TOOL_CACHE | Chemin du répertoire contenant des outils préinstallés pour les exécuteurs hébergés par GitHub. Pour plus d’informations, consultez « Exécuteurs hébergés par GitHub ». Par exemple, C:\hostedtoolcache\windows |
Remarque
Si vous devez utiliser l’URL de l’exécution d’un workflow à partir d’un travail, vous pouvez combiner ces variables : $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
Conventions de nommage pour les variables de configuration
Les règles suivantes s’appliquent aux noms des variables de configuration :
- Peuvent uniquement contenir des caractères alphanumériques (
[a-z]
,[A-Z]
,[0-9]
) ou des traits de soulignement (_
). Les espaces ne sont pas autorisés. - Ne doit pas commencer par le préfixe
GITHUB_
. - Ne doit pas commencer par un chiffre.
- Ne sont pas sensibles à la casse lorsqu’ils sont référencés. GitHub enregistre les noms de secrets en majuscules, quelle que soit la façon dont ils sont entrés.
- Doivent être uniques au référentiel, à l’organisation ou à l’entreprise où ils sont créés.
Conventions d’affectation de noms pour les variables d’environnement
Lorsque vous définissez une variable d’environnement, vous ne pouvez pas utiliser les noms de variable d’environnement par défaut. Pour obtenir la liste complète de ces noms, consultez Références des variables ci-dessous. Si vous tentez de remplacer la valeur de l’une de ces variables par défaut, l’affectation est ignorée.
Remarque
Vous pouvez lister l’ensemble des variables d’environnement disponibles pour une étape de workflow en utilisant run: env
dans une étape, puis en examinant la sortie de cette étape.
Priorité des variables de configuration
S’il existe une variable du même nom à plusieurs niveaux, la variable au niveau le plus bas est prioritaire. Par exemple, si une variable au niveau de l’organisation porte le même nom qu’une variable au niveau du dépôt, celle-ci est prioritaire. De même, si une organisation, un dépôt et un environnement ont tous une variable portant le même nom, la variable au niveau de l’environnement est prioritaire.
Pour les workflows réutilisables, les variables du dépôt du workflow de l’appelant sont utilisées. Les variables du dépôt qui contient le workflow appelé ne sont pas mises à la disposition du workflow de l’appelant.
Limites pour les variables de configuration
La taille des variables individuelles est limitée à 48 Ko.
Vous pouvez stocker jusqu’à 1 000 variables d’organisation, 500 variables par dépôt et 100 variables par environnement. La limite de taille combinée totale pour les variables d’organisation et de référentiel est de 256 Mo par exécution de workflow.
Un workflow créé dans un dépôt peut accéder au nombre de variables suivant :
- Jusqu’à 500 variables de dépôt, si la taille totale des variables de dépôt est inférieure à 256 Ko. Si la taille totale des variables de dépôt dépasse 256 Ko, seules les variables de dépôt qui se trouvent sous la limite sont disponibles (triées par ordre alphabétique par nom de variable).
- Jusqu’à 1 000 variables d’organisation, si la taille totale combinée des variables de dépôt et d’organisation est inférieure à 256 Ko. Si la taille totale combinée des variables d’organisation et de dépôt dépasse 256 Ko, seules les variables d’organisation qui se trouvent en dessous de cette limite sont disponibles (après prise en compte des variables de dépôt et triées par ordre alphabétique par nom de variable).
- Jusqu’à 100 variables au niveau de l’environnement.
Remarque
Les variables d'environnement ne sont pas prises en compte dans la limite de 256 Ko. Si vous dépassez la limite de taille combinée pour les variables de référentiel et d’organisation et que vous avez toujours besoin de variables supplémentaires, vous pouvez utiliser un environnement et y définir des variables supplémentaires.
Contextes pris en charge
Vous utilisez généralement le contexte env
ou github
pour accéder aux valeurs des variables figurant dans les parties du workflow traitées avant que les travaux soient envoyés aux exécuteurs.
Avertissement
N’imprimez pas le contexte github
dans les journaux. Il contient des informations sensibles.
Context | Cas d’utilisation | Exemple |
---|---|---|
env | Référencer des variables personnalisées définies dans le workflow. | ${{ env.MY_VARIABLE }} |
github | Référencer des informations sur l’exécution du workflow et l’événement qui a déclenché cette exécution. | ${{ github.repository }} |