# Stocker des informations dans des variables GitHub définit les variables par défaut pour chaque GitHub Actions exécution de flux de travail. Vous pouvez également définir des variables personnalisées à utiliser dans un seul ou plusieurs flux de travail. ## 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`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env) au niveau supérieur du fichier de workflow. * Le contenu d’un travail au sein d’un workflow, en utilisant [`jobs..env`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idenv). * Une étape spécifique dans un travail, en utilisant [`jobs..steps[*].env`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsenv). ```yaml copy 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 s’effectue sur l’exécuteur. Les commandes des étapes `run` d’un workflow, ou d’une action référencée, sont traitées par le shell que vous utilisez sur l’exécuteur. Les instructions contenues dans les autres parties d’un flux de travail sont traitées 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](#using-contexts-to-access-variable-values) ». É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 « [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell) ». ## 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](#creating-configuration-variables-for-an-organization), du [dépôt](#creating-configuration-variables-for-a-repository) ou de l’[environnement](#creating-configuration-variables-for-an-environment). 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](#using-the-vars-context-to-access-configuration-variable-values) ». ### 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 d’organisation, vous devez avoir `admin` accès. Pour un référentiel de comptes personnels, vous devez être collaborateur du référentiel. 1. Sur GitHub, accédez à la page principale du référentiel. 2. Sous le nom de votre référentiel, cliquez sur ** Paramètres**. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant **** , puis cliquez sur **Paramètres**. ![Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.](/assets/images/help/repository/repo-actions-settings.png) 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**. ![Capture d’écran de la page « Actions secrets et variables ». L’onglet « Variables » est présenté en orange foncé.](/assets/images/help/repository/actions-variables-tab.png) 1. Cliquez sur **Nouvelle variable de dépôt**. 2. Dans le champ **Nom**, entrez un nom pour la variable. 3. Dans le champ **Valeur**, entrez la valeur de la variable. 4. 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 d’un 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 référentiel d’organisation, vous devez disposer d’un accès `admin`. Pour plus d’informations sur les environnements, consultez [Gestion des environnements pour le déploiement](/fr/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). 1. Sur GitHub, accédez à la page principale du référentiel. 2. Sous le nom de votre référentiel, cliquez sur ** Paramètres**. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant **** , puis cliquez sur **Paramètres**. ![Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.](/assets/images/help/repository/repo-actions-settings.png) 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. Les propriétaires et utilisateurs de l’organisation disposant des autorisations « Gérer les variables Actions de l’organisation » ou « Gérer les secrets d’actions de l’organisation » peuvent créer des secrets ou des variables au niveau de l’organisation. Pour plus d’informations, consultez [Autorisations des rôles d’organisation personnalisés](/fr/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles). 1. Sur GitHub, accédez à la page principale de l’organisation. 2. Sous le nom de votre organisation, cliquez sur ** Settings**. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant **** , puis cliquez sur **Paramètres**. ![Capture d’écran des onglets dans le profil d’une organisation. L’onglet « Paramètres » est présenté en orange foncé.](/assets/images/help/discussions/org-settings-global-nav-update.png) 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**. ![Capture d’écran de la page « Actions : Secrets et Variables ». L’onglet « Variables » est présenté en orange foncé.](/assets/images/help/repository/actions-variables-tab.png) > \[!NOTE] > La page « Secrets et variables Actions » peut ne pas afficher d’onglets distincts pour les secrets et les variables en fonction de vos autorisations. Les propriétaires d’organisation et les utilisateurs disposant des autorisations « Gérer les variables Actions de l’organisation » et « Gérer les secrets Actions de l’organisation » voient les onglets **Variables** et **Secrets**. Pour plus d’informations, consultez « [Autorisations des rôles d’organisation personnalisés](/fr/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles) ». 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**. ## 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 [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts). 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 « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability) ». 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 du runner, GitHub Actions vous permet de définir et de lire des paires clé-valeur `env` à l’aide des 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. Toutefois, vous ne pouvez pas utiliser les variables d’environnement de l’exécuteur dans des 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 conditionnelle `if`, qui détermine si une tâche ou une étape est envoyée au runner, est toujours traitée par GitHub Actions. Vous devez donc utiliser un contexte dans une `if` instruction conditionnelle pour accéder à la valeur d’une variable. ```yaml copy 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`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#env-context). 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. ```yaml run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" ``` > \[!NOTE] > Les contextes sont généralement indiqués à l’aide du signe dollar et des accolades, comme `${{ context.property }}`. Dans un `if` conditionnel, le `${{` et `}}` sont facultatifs, mais si vous les utilisez, ils doivent contenir l’intégralité de l’instruction de comparaison, comme indiqué ci-dessus. > \[!WARNING] > Lors de la création de flux de travail et d’actions, vous devez toujours déterminer si votre code pourrait exécuter des entrées non fiables provenant de personnes malveillantes potentielles. 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 « [Informations de référence sur l’utilisation sécurisée](/fr/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks) ». ### 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 « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context) ». 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. ```yaml copy 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 }} ``` ## Détection du système d’exploitation Vous pouvez écrire un fichier de flux de travail unique qui peut être utilisé pour différents systèmes d’exploitation à l’aide de la `RUNNER_OS` variable d’environnement par défaut et de la propriété `${{ runner.os }}`de contexte correspondante. 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. ```yaml copy 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. `if` les expressions conditionnelles sont traitées par GitHub Actions, et seules les étapes pour lesquelles la vérification s’avère `true` sont envoyées à l’agent d’exécution. 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 « [Commandes de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable) ». 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 « [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs) ». ## Étapes suivantes Pour obtenir des informations de référence, consultez [Références des variables](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/variables).