Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
À propos des variables
Les variables permettent de stocker et de réutiliser des informations de configuration non sensibles. Vous pouvez stocker des données de configuration telles que des indicateurs de compilateur, des noms d’utilisateur ou des noms de serveur en tant que variables. Les variables sont interpolées sur la machine d’exécuteur qui exécute votre workflow. Les commandes qui s’exécutent dans des actions ou des étapes de workflow peuvent créer, lire ou modifier des variables.
Vous pouvez définir vos propres variables personnalisées, ou utiliser les variables d’environnement par défaut que GitHub définit automatiquement. Pour plus d’informations, consultez « Variables d’environnement par défaut ».
Vous pouvez définir une variable personnalisée de deux façons.
- Pour définir une variable d’environnement à utiliser dans un workflow unique, vous pouvez utiliser la clé
env
dans le fichier de workflow. Pour plus d’informations, consultez « Définition de variables d’environnement pour un workflow unique ». - Pour définir une variable de configuration pour plusieurs workflows, vous pouvez la définir au niveau de l’organisation, du dépôt ou de l’environnement. Pour plus d’informations, consultez « Définition de variables de configuration pour plusieurs workflows ».
Avertissement : Par défaut, les variables sont masquées dans vos sorties de build. Si vous avez besoin d’une plus grande sécurité pour les informations sensibles, telles que les mots de passe, utilisez plutôt des secrets. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».
Définition de variables d’environnement pour un workflow unique
Pour configurer une variable d’environnement à utiliser dans un workflow unique, vous pouvez la définir en utilisant la clé env
dans le fichier du workflow. L’étendue d’une variable personnalisée définie par cette méthode est limitée à l’élément dans lequel elle est définie. Vous pouvez définir des variables dont l’étendue est :
- Le workflow entier, en utilisant
env
au niveau supérieur du fichier de workflow. - Le contenu d’un travail au sein d’un workflow, en utilisant
jobs.<job_id>.env
. - Une étape spécifique dans un travail, en utilisant
jobs.<job_id>.steps[*].env
.
name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
Vous pouvez accéder aux valeurs de variable env
à l’aide de variables d’environnement d’exécuteur ou de contextes. L’exemple ci-dessus montre trois variables personnalisées utilisées en tant que variables d’environnement d'exécuteur dans une commande echo
: $DAY_OF_WEEK
, $Greeting
et $First_Name
. Les valeurs de ces variables sont définies et limitées respectivement au niveau du workflow, du travail et de l’étape. L'interpolation de ces variables se fait sur l’exécuteur.
Les commandes des étapes run
d'un flux de travail, ou d'une action référencée, sont traitées par l'interpréteur de commandes que vous utilisez sur l’exécuteur. Les instructions contenues dans les autres parties d'un flux de travail sont traitées par GitHub Actions et ne sont pas envoyées à l’exécuteur. Vous pouvez utiliser des variables d'environnement d'exécuteur ou des contextes dans les étapes run
, mais dans les parties d'un flux de travail qui ne sont pas envoyées à l'exécution, vous devez utiliser des contextes pour accéder aux valeurs des variables. Pour plus d’informations, consultez « Utilisation du contexte pour accéder aux valeurs des variables ».
Étant donné que l’interpolation des variables d’environnement d’exécuteur est effectuée une fois qu’un travail de workflow est envoyé à une machine d’exécuteur, vous devez utiliser la syntaxe appropriée pour l’interpréteur de commandes utilisé sur l’exécuteur. Dans cet exemple, le workflow spécifie ubuntu-latest
. Par défaut, les exécuteurs Linux utilisent l’interpréteur de commandes bash. Vous devez donc utiliser la syntaxe $NAME
. Par défaut, les exécuteurs Windows utilisent PowerShell. Vous devez donc utiliser la syntaxe $env:NAME
. Pour plus d’informations sur les interpréteurs de commandes, consultez « Workflow syntax for GitHub Actions ».
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 des variables d’environnement par défaut, consultez « Variables d’environnement par défaut » 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.
Définition de variables de configuration pour plusieurs workflows
Remarque : Les variables de configuration pour GitHub Actions sont en version bêta et sont susceptibles d’être modifiées.
Vous pouvez créer des variables de configuration à utiliser dans plusieurs workflows et les définir au niveau de l’organisation, du dépôt ou de l’environnement.
Par exemple, vous pouvez utiliser des variables de configuration pour définir des valeurs par défaut pour les paramètres passés aux outils de génération au niveau de l’organisation, mais autoriser ensuite les propriétaires de dépôts à remplacer ces paramètres au cas par cas.
Lorsque vous définissez des variables de configuration, elles sont automatiquement disponibles dans le contexte vars
. Pour plus d’informations, consultez « Utilisation du contexte vars
pour accéder aux valeurs des variables de configuration ».
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.
Conventions de nommage pour les variables de configuration
Les règles suivantes s’appliquent aux noms des variables de configuration :
- Les noms peuvent contenir uniquement des caractères alphanumériques (
[a-z]
,[A-Z]
,[0-9]
) ou des traits de soulignement (_
). Les espaces ne sont pas autorisés. - Les noms ne doivent pas commencer par le préfixe
GITHUB_
. - Les noms ne doivent pas commencer par un chiffre.
- Les noms ne respectent pas la casse.
- Les noms doivent être uniques au niveau où ils sont créés.
Création de variables de configuration pour un dépôt
Pour créer des secrets ou des variables sur GitHub pour un référentiel de compte personnel, vous devez être le propriétaire du référentiel. Pour créer des secrets ou des variables sur GitHub pour un référentiel d’une organisation, vous devez disposer d’un accès admin
. Enfin, pour créer des secrets ou des variables pour un référentiel de compte personnel ou un référentiel d’organisation via l’API REST, vous devez disposer d’un accès collaborateur.
-
Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.
-
Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
-
Dans la section Sécurité de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.
-
Cliquez sur l’onglet Variables.
-
Cliquez sur Nouvelle variable de dépôt.
-
Dans le champ Nom, entrez un nom pour la variable.
-
Dans le champ Valeur, entrez la valeur de la variable.
-
Cliquez sur Ajouter une variable.
Création de variables de configuration pour un environnement
Pour créer des secrets pour un environnement dans un référentiel de compte personnel, vous devez être le propriétaire du référentiel. Pour créer des secrets ou des variables pour un environnement dans un référentiel d’organisation, vous devez disposer d’un accès admin
. Pour plus d’informations sur les environnements, consultez « Utilisation d’environnements pour le déploiement ».
-
Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.
-
Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
-
Dans la barre latérale gauche, cliquez sur Environnements.
-
Cliquez sur l’environnement auquel vous souhaitez ajouter une variable.
-
Sous Variables d’environnement, cliquez sur Ajouter une variable.
-
Dans le champ Nom, entrez un nom pour la variable.
-
Dans le champ Valeur, entrez la valeur de la variable.
-
Cliquez sur Ajouter une variable.
Création de variables de configuration pour une organisation
Quand vous créez un secret ou une variable dans une organisation, vous pouvez utiliser une stratégie pour limiter l’accès par dépôt. Par exemple, vous pouvez accorder l’accès à tous les dépôts, ou limiter l’accès aux seuls dépôts privés ou à une liste spécifiée de dépôts.
Les propriétaires d’organisations peuvent créer des secrets ou des variables au niveau de l’organisation.
-
Sur votre instance GitHub Enterprise Server, accédez à la page principale de l’organisation.
-
Sous le nom de votre organisation, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
-
Dans la section Sécurité de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.
-
Cliquez sur l’onglet Variables.
-
Cliquez sur Nouvelle variable d’organisation.
-
Dans le champ Nom, entrez un nom pour la variable.
-
Dans le champ Valeur, entrez la valeur de la variable.
-
Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.
-
Cliquez sur Ajouter une variable.
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 10 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 référentiel, si la taille totale des variables de référentiel est inférieure à 10 Mo. Si la taille totale des variables de référentiel dépasse 10 Mo, seules les variables de référentiel qui se trouvent sous la limite sont disponibles (triées par ordre alphabétique et par nom de variable).
- Jusqu’à 1 000 variables d’organisation, si la taille totale combinée des variables de référentiel et d’organisation est inférieure à 10 Mo. Si la taille totale combinée des variables d’organisation et de dépôt dépasse 10 Mo, seules les variables d’organisation qui se trouvent en dessous de cette limite sont disponibles (après prise en compte des variables de référentiel et triées par ordre alphabétique et par nom de variable).
- Jusqu’à 100 variables au niveau de l’environnement.
Remarque : les variables d’environnement ne sont pas comptabilisées dans la limite de taille totale de 10 Mo. 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.
Utilisation de contextes pour accéder aux valeurs des variables
Les contextes offrent un moyen d’accéder aux informations sur les exécutions de workflow, les variables, les environnements d’exécuteur, les travaux et les étapes. Pour plus d’informations, consultez « Contextes ». Il existe de nombreux autres contextes que vous pouvez utiliser à diverses fins dans vos workflows. Pour plus d’informations sur l’emplacement où vous pouvez utiliser des contextes spécifiques au sein d’un workflow, consultez « Contextes ».
Vous pouvez accéder aux valeurs des variables d'environnement à l'aide du contexte env
et aux valeurs des variables de configuration à l'aide du contexte vars
.
Utilisation du contexte env
pour accéder aux valeurs des variables d’environnement
Outre les variables d’environnement d’exécuteur, GitHub Actions vous permet de définir et de lire des valeurs de clés env
à l’aide de contextes. Les variables d’environnement et les contextes sont destinés à être utilisés à différents points du workflow.
Les étapes run
d'un flux de travail, ou d'une action référencée, sont traitées par un exécuteur. Par conséquent, vous pouvez utiliser les variables d'environnement de l’exécuteur ici, en utilisant la syntaxe appropriée pour le shell que vous utilisez sur l’exécuteur : par exemple, $NAME
pour le shell bash sur un exécuteur Linux ou $env:NAME
pour PowerShell sur un exécuteur Windows. Dans la plupart des cas, vous pouvez également utiliser des contextes, avec la syntaxe ${{ CONTEXT.PROPERTY }}
, pour accéder à la même valeur. La différence est que le contexte sera interpolé et remplacé par une chaîne de caractères avant que le projet ne soit envoyé à un exécuteur.
Cependant, vous ne pouvez pas utiliser les variables d'environnement d'exécuteur dans les parties d'un flux de travail qui sont traitées par GitHub Actions et qui ne sont pas envoyées à l’exécuteur. À la place, vous devez utiliser des contextes. Par exemple, une condition if
, qui détermine si un travail ou une étape sont envoyés à l’exécuteur, est toujours traitée par GitHub Actions. Vous devez donc utiliser un contexte dans une instruction conditionnelle if
pour accéder à la valeur d’une variable.
name: Conditional env variable on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" if: ${{ env.DAY_OF_WEEK == 'Monday' }} run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
Dans cette modification de l’exemple précédent, nous avons introduit une condition if
. L’étape de workflow est désormais exécutée uniquement si la variable DAY_OF_WEEK
a pour valeur « Monday » (Lundi). Nous accédons à cette valeur à partir de l’instruction conditionnelle if
en utilisant le contexte env
. Le contexte env
n'est pas nécessaire pour les variables référencées dans la commande run
. Elles sont référencées en tant que variables d'environnement de l'exécuteur et sont interpolées après la réception du projet par l’exécuteur. Nous aurions cependant pu choisir d'interpoler ces variables avant d'envoyer le projet à l’exécuteur, en utilisant des contextes. La production résultante serait la même.
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"
Remarque : Les contextes sont généralement indiqués par un signe dollar et des accolades, comme ${{ context.property }}
. Dans une condition if
, les éléments ${{
et }}
sont facultatifs, mais si vous les utilisez, ils doivent contenir l’instruction de comparaison entière, comme indiqué ci-dessus.
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.
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 }} |
Avertissement : Au moment de la création de workflows et d’actions, vous devez toujours déterminer si votre code peut exécuter une entrée non fiable provenant d’attaquants potentiels. Certains contextes doivent être traités comme des entrées non fiables, car un attaquant peut insérer son propre contenu malveillant. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».
Utilisation du contexte vars
pour accéder à des valeurs de variable de configuration
Les variables de configuration sont accessibles dans le workflow à l’aide du contexte vars
. Pour plus d’informations, consultez « Contextes ».
Si aucune variable de configuration n’a été définie, la valeur retournée d’un contexte référençant la variable est une chaîne vide.
L’exemple suivant montre l’utilisation de variables de configuration avec le contexte vars
dans un workflow. Chacune des variables de configuration suivantes a été définie au niveau du dépôt, de l’organisation ou de l’environnement.
on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }}
on:
workflow_dispatch:
env:
# Setting an environment variable with the value of a configuration variable
env_var: ${{ vars.ENV_CONTEXT_VAR }}
jobs:
display-variables:
name: ${{ vars.JOB_NAME }}
# You can use configuration variables with the `vars` context for dynamic jobs
if: ${{ vars.USE_VARIABLES == 'true' }}
runs-on: ${{ vars.RUNNER }}
environment: ${{ vars.ENVIRONMENT_STAGE }}
steps:
- name: Use variables
run: |
echo "repository variable : $REPOSITORY_VAR"
echo "organization variable : $ORGANIZATION_VAR"
echo "overridden variable : $OVERRIDE_VAR"
echo "variable from shell environment : $env_var"
env:
REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
- name: ${{ vars.HELLO_WORLD_STEP }}
if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
uses: actions/hello-world-javascript-action@main
with:
who-to-greet: ${{ vars.GREET_NAME }}
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 « Définition des variables d’environnement pour un seul flux de travail » 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 : http(s)://HOSTNAME/api/v3 . |
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 : http(s)://HOSTNAME/api/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 le format est refs/heads/<branch_name> pour les branches, refs/pull/<pr_number>/merge pour les requêtes de tirage et refs/tags/<tag_name> pour les étiquettes. 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 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 Enterprise Server. Par exemple : https://HOSTNAME . |
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_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 « Utilisation des exécuteurs hébergés par GitHub ». Par exemple, C:\hostedtoolcache\windows |
Note : si vous devez utiliser l’URL de l’exécution d’un flux de travail à partir d’un projet, vous pouvez combiner ces variables :$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
Détection du système d’exploitation
Vous pouvez écrire un fichier de workflow individuel qui peut être utilisé pour différents systèmes d’exploitation à l’aide de la variable d’environnement par défaut RUNNER_OS
et de la propriété de contexte correspondante ${{ runner.os }}
. Par exemple, le workflow suivant peut être exécuté correctement si vous avez remplacé le système d’exploitation macos-latest
par windows-latest
sans avoir à modifier la syntaxe des variables d’environnement, ce qui diffère selon l’interpréteur de commandes utilisé par l’exécuteur.
on: workflow_dispatch jobs: if-Windows-else: runs-on: macos-latest steps: - name: condition 1 if: runner.os == 'Windows' run: echo "The operating system on the runner is $env:RUNNER_OS." - name: condition 2 if: runner.os != 'Windows' run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
on: workflow_dispatch
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
Dans cet exemple, les deux instructions if
vérifient la propriété os
du contexte runner
pour déterminer le système d’exploitation de l’exécuteur. Les conditions if
sont traitées par GitHub Actions et seules les étapes où la vérification est résolue comme true
sont envoyées à l’exécuteur. Ici, l’une des vérifications sera toujours true
et l’autre false
, si bien qu’une seule de ces étapes est envoyée à l’exécuteur. Une fois le travail envoyé à l’exécuteur, l’étape est exécutée et la variable d’environnement dans la commande echo
est interpolée à l’aide de la syntaxe appropriée ($env:NAME
pour PowerShell sur Windows, et $NAME
pour bash et sh sur Linux et macOS). Dans cet exemple, l’instruction runs-on: macos-latest
signifie que la deuxième étape sera exécutée.
Transmission de valeurs entre les étapes et les travaux dans un workflow
Si vous générez une valeur dans une étape d’un travail, vous pouvez utiliser cette valeur dans les étapes suivantes du même travail en affectant la valeur à une variable d’environnement existante ou nouvelle, puis en écrivant cette dernière dans le fichier d’environnement GITHUB_ENV
. Le fichier d’environnement peut être utilisé directement par une action ou à partir d’une commande shell dans le fichier de workflow à l’aide du mot clé run
. Pour plus d’informations, consultez « Workflow commands for GitHub Actions ».
Si vous souhaitez transmettre une valeur d’une étape d’un travail dans un workflow vers une étape d’un autre travail dans le workflow, vous pouvez définir la valeur en tant que sortie de travail. Vous pouvez ensuite référencer cette sortie de travail à partir d’une étape dans un autre travail. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».