Variables

À 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 ».

Définition de variables d’environnement pour un workflow unique

Pour définir une variable d’environnement personnalisée pour un workflow unique, vous pouvez la définir à l’aide de la clé env dans le fichier de 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 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. Pour plus d’informations sur l’accès aux valeurs de variable à l’aide de contextes, consultez « Utilisation de contextes pour accéder aux valeurs de variable ».

É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. Si le workflow a spécifié un exécuteur Windows, vous utiliserez la syntaxe pour PowerShell, $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.

Toutes les nouvelles variables que vous définissez et qui pointent vers un emplacement dans le système de fichiers doivent avoir un suffixe _PATH. Les variables par défaut GITHUB_ENV et GITHUB_WORKSPACE sont des exceptions à cette convention.

Définition de variables de configuration pour plusieurs workflows

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 dépôt référentiel de personnel ou un référentiel d’organisation via l’API REST, vous devez disposer d’un accès collaborateur.

1. Dans GitHub.com, accédez à la page principale du dépôt.
2. 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.
3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.
4. Cliquez sur l’onglet Variables.
5. Cliquez sur Nouvelle variable de dépôt.
6. Dans le champ Nom, entrez un nom pour la variable.
7. Dans le champ Valeur, entrez la valeur de la variable.
8. Cliquez sur Ajouter une variable.

Création de variables de configuration pour un environnement

Pour créer des secrets ou des variables pour un environnement dans un dépôt de compte personnel, vous devez être le propriétaire du dépôt. Pour créer des secrets ou des variables pour un environnement dans un dépôt d’organisation, vous devez avoir l’accès admin. Pour plus d’informations sur les environnements, consultez « Utilisation d’environnements pour le déploiement ».

1. Dans GitHub.com, accédez à la page principale du dépôt.
2. 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.
3. Dans la barre latérale gauche, cliquez sur Environnements.
4. Cliquez sur l’environnement auquel vous souhaitez ajouter une variable.
5. Sous Variables d’environnement, cliquez sur Ajouter une variable.
6. Dans le champ Nom, entrez un nom pour la variable.
7. Dans le champ Valeur, entrez la valeur de la variable.
8. 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.

Pour créer des secrets ou des variables au niveau de l’organisation, vous devez être propriétaire d'une organisation.

1. Sur GitHub.com, accédez à la page principale de l’organisation.

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

   

3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.

4. Cliquez sur l’onglet Variables.

   

5. Cliquez sur Nouvelle variable d’organisation.

6. Dans le champ Nom, entrez un nom pour la variable.

7. Dans le champ Valeur, entrez la valeur de la variable.

8. Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.

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

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 de variable 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 variables d’environnement d’exécuteur sont toujours interpolées sur la machine d’exécuteur. Toutefois, les parties d’un workflow sont traitées par GitHub Actions et ne sont pas envoyées à l’exécuteur. Vous ne pouvez pas utiliser de variables d’environnement dans ces parties d’un fichier de workflow. À la place, vous pouvez 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 pouvez utiliser un contexte dans une instruction conditionnelle if pour accéder à la valeur d’une variable.

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

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.

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.

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.

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.

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

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