Tout savoir sur l’utilisation des variables d’environnement GitHub Actions

Pour optimiser la mise en production de votre code, nous vous recommandons de déployer un pipeline d’intégration et de livraison continues (CI/CD). Ce type de pipeline automatise la vérification des modifications du code et fournit des outils pour automatiser leur mise en production.

Pour le mettre en place, beaucoup d’équipes s’appuient sur leur système de contrôle des versions existant. GitHub est l’un des plus populaires et il propose justement la plateforme GitHub Actions, qui permet aux développeurs de générer, tester et déployer leur code automatiquement, et contribue ainsi à la création de pipelines CI/CD sécurisés.

Dans GitHub Actions, de nombreux travaux ont besoin d’un accès aux variables d’environnement. Vous pouvez définir ces variables dès le départ et limiter leur accès aux pipelines qui s’exécutent dans cet environnement précis. Ainsi, vous pouvez faire évoluer le comportement du pipeline CI/CD en jouant sur les variables d’environnement, par exemple en passant sur la création d’une version de production optimisée avant de déployer effectivement l’application en production.

Cet article présente les variables d’environnement proposées par GitHub Action et explique dans quels cas les utiliser.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

• Un accès à un ordinateur sur lequel est installé un éditeur de code (ce tutoriel utilise Visual Studio Code), ainsi qu’à un compte GitHub.

• Notre extrait de code. Vous y trouverez une petite application Java qui nous permet d’expliquer le fonctionnement des variables d’environnement.

Saviez-vous que nous proposons un plugin Snyk pour Visual Studio Code avec lequel vous pouvez analyser votre projet à mesure que vous codez ? Consultez notre documentation pour en savoir plus.

Possibilités offertes par les variables d’environnement GitHub Actions

Une fois que vous avez téléchargé l’extrait de code, créez un dépôt GitHub et importez-y le code.

Ce code contient un exemple de fichier de workflow GitHub Actions. Le fichier, .github/workflows/pipeline.yml, se présente comme suit :

1name: Java CI with Maven
2
3on:
4  push:
5    branches: [ "main" ]
6  pull_request:
7    branches: [ "main" ]
8
9jobs:
10  build:
11
12    runs-on: ubuntu-latest
13
14    steps:
15    - uses: actions/checkout@v3
16    - name: Set up JDK 21
17      uses: actions/setup-java@v3
18      with:
19        java-version: '21'
20        distribution: 'temurin'
21        cache: maven
22    - name: Build with Maven
23      run: mvn -B package --file pom.xml

Ce fichier définit un workflow très simple permettant de générer notre application Java avec Maven.

Dans notre fichier de configuration YAML, nous pouvons définir des variables d’environnement sur trois niveaux : workflow, travail et étape. Ces différents niveaux déterminent leur portée. Les variables d’environnement au niveau du workflow s’appliquent à l’ensemble du workflow. Au niveau d’un travail, elles s’appliquent à des travaux donnés. Enfin, les variables d’environnement d’étape concernent des étapes spécifiques.

Voyons chacune de ces variables plus en détail.

Variables d’environnement de workflow

Pour créer une variable d’environnement de workflow, nous devons la définir en haut de notre fichier YAML. Ajoutez le code suivant sous la variable NAME, en haut du fichier :

1env:
2  NAME: 'Snyk Demo'

Ce code définit une variable d’environnement appelée NAME à laquelle nous pouvons désormais accéder partout dans le workflow. Pour accéder à cette variable, nous avons besoin d’une syntaxe bien précise, proche de celle utilisée pour accéder aux variables d’environnement UNIX. Pour utiliser notre variable NAME, nous devons lui adjoindre le préfixe $. Elle devient donc $NAME.

Ajoutons à la ligne 23 une nouvelle étape du workflow permettant d’afficher son contenu :

1- name: Print name
2  run: echo "Hello $NAME"

Validez cette modification et envoyez-la sur le dépôt.

Ensuite, ouvrez GitHub dans un navigateur et rendez-vous dans l’onglet Actions du référentiel. Sélectionnez le workflow le plus récent sous Jobs et ouvrez le résultat de notre travail de génération. Cliquez sur Print name. Une fois le menu développé, vous verrez que la variable d’environnement est affichée, comme illustré dans l’image ci-dessous.

Les variables d’environnement au niveau du workflow s’appliquent à l’ensemble des travaux et étapes de ce workflow. Par exemple, nous pouvons faire appel à une variable de ce type pour définir le type d’environnement dans lequel le workflow s’exécute : développement, test ou production. Cela peut être utile pour les applications Node.js créées avec npm, car elles peuvent ainsi utiliser la variable NODE_ENV. Avec cette variable, chaque travail peut adopter un comportement approprié pour cet environnement spécifique. Pour en savoir plus sur la marche à suivre pour sécuriser la publication de vos paquets npm, lisez notre article consacré à ce sujet.

Variables d’environnement de travail

Voyons maintenant la définition de variables d’environnement de travail et d’étape. La méthode est la même que pour les variables d’environnement de workflow, mais nous les définissons cette fois-ci dans la section correspondante.

Pour la variable de travail, nous définissons la version de Java comme suit :

1jobs:
2  build:
3    env:
4        JAVA_VERSION: '21'

Nous pouvons désormais utiliser cette variable comme nous l’avons fait précédemment, mais cette fois-ci au sein de nos étapes.

1steps:
2- uses: actions/checkout@v3
3- name: Set up JDK ${{env.JAVA_VERSION}}
4  uses: actions/setup-java@v3
5  with:
6    java-version: ${{env.JAVA_VERSION}}
7    distribution: 'temurin'
8    cache: maven

Vous remarquerez néanmoins que notre variable d’environnement JAVA_VERSION implique une syntaxe un peu particulière. Il s’agit d’un exemple d’accès par le biais de contextes. Les contextes permettent à GitHub Actions d’utiliser nos variables d’environnement sur n’importe quelle machine virtuelle, car ces travaux ne sont pas toujours exécutés sur la machine virtuelle sur laquelle nous avons déclaré notre environnement.

Vous pouvez utiliser des variables d’environnement de travail pour remplacer un environnement au niveau du workflow lorsqu’un travail précis demande une valeur différente pour une variable de workflow déjà déclarée ou limite la portée d’une variable à un travail donné.

Comme le montre l’exemple ci-dessus, nous pouvons utiliser une variable d’environnement de travail pour définir la version de Java, ce qui nous permet de l’utiliser dans chaque travail. Pour utiliser une autre version de Java à l’avenir, nous n’avons qu’une seule modification à faire pour que toutes les étapes du travail utilisent automatiquement la nouvelle version.

Maintenant que vous travaillez sur une action GitHub, vous pouvez facilement intégrer Snyk à GitHub Actions et analyser votre projet sans attendre. Nous proposons une intégration Snyk pour GitHub Actions pour vous faciliter la tâche. N’hésitez pas à créer un compte Snyk si vous ne l’avez pas déjà fait pour intégrer les analyses dès maintenant.

Variables d’environnement d’étape

Nous pouvons également définir des variables au sein d’une étape. Voici un exemple. Modifiez l’étape Print name du fichier pipeline.yml pour reproduire l’extrait de code ci-dessous :

1- name: Print name
2  run: echo "Hello $NAME. $BUILD. Using Java Version $JAVA_VERSION"
3  env:
4    BUILD: 'We are currently running the Build job'

Les variables d’environnement d’étape ont une portée limitée à une seule étape. Elles sont utiles pour définir les chemins de fichier d’entrée ou de sortie pour une étape précise. Dans l’exemple de code ci-dessus, nous avons utilisé une variable d’étape pour afficher du texte.

Vous trouverez ci-dessous le fichier YAML de workflow GitHub complet avec les nouvelles variables de travail et d’étape :

1name: Java CI with Maven
2
3env:
4  NAME: 'Snyk Demo'
5
6on:
7  push:
8    branches: [ "main" ]
9  pull_request:
10    branches: [ "main" ]
11
12jobs:
13  build:
14    env:
15        JAVA_VERSION: '21'
16
17    runs-on: ubuntu-latest
18
19    steps:
20    - uses: actions/checkout@v3
21    - name: Set up JDK ${{env.JAVA_VERSION}}
22      uses: actions/setup-java@v3
23      with:
24        java-version: ${{env.JAVA_VERSION}}
25        distribution: 'temurin'
26        cache: maven
27    - name: Build with Maven
28      run: mvn -B package --file pom.xml
29    - name: Print name
30      run: echo "Hello $NAME. $BUILD. Using Java Version $JAVA_VERSION"
31      env:
32        BUILD: 'We are currently running the Build job'

Importez ce nouveau workflow dans GitHub et étudiez la sortie générée, qui devrait ressembler à l’image ci-dessous.

Nous avons configuré notre variable d’environnement à l’aide de contextes, et notre étape d’affichage de texte fonctionne de la manière attendue.

Sans les contextes, nous aurions fait face à l’erreur suivante :

En effet, l’action setup-java n’a pas accès au même environnement, et il est donc nécessaire de passer par les contextes pour qu’elle puisse utiliser notre variable.

Utilisation des variables par défaut et des secrets de GitHub

En plus de définir des variables d’environnement, vous pouvez accéder depuis un workflow à des variables par défaut de GitHub. Ces variables nous permettent de consulter le dépôt GitHub, l’action GitHub et l’exécuteur du workflow. Vous pouvez les utiliser comme les variables d’environnement que vous définissez vous-même. Vous devez y accéder en passant par des contextes si vous utilisez GitHub Actions.

Les secrets GitHub constituent le dernier type de variable d’environnement. Vous pouvez les utiliser pour les variables qui contiennent des données sensibles, car GitHub les chiffre et les rend disponibles dans votre workflow.

Pour créer ces variables d’environnement chiffrées dans GitHub, rendez-vous dans la section Settings du dépôt, puis sélectionnez Secrets and variables et enfin Actions dans le menu de gauche. Ensuite, cliquez sur New repository secret et saisissez un nom et une valeur. Créez un secret appelé API_KEY et donnez-lui une valeur aléatoire, comme indiqué ci-dessous.

Pour utiliser notre secret dans le workflow, nous utilisons la même syntaxe qu’avec les contextes qui nous ont permis de définir des variables d’environnement dans GitHub Actions. Une petite différence : le préfixe ne sera pas env., mais secrets.

1${{secrets.API_KEY}}

Ajoutez ${{secrets.API_KEY}} à l’instruction Print que nous avons déjà intégrée au workflow du fichier YAML. Votre code doit être identique à l’extrait suivant :

1- name: Print name
2  run: echo "Hello $NAME. $BUILD. Using Java Version $JAVA_VERSION. My API_KEY is ${{secrets.API_KEY}}"
3  env:
4    BUILD: 'We are currently running the Build job'

Validez les modifications, puis importez-les dans le référentiel. Rendez-vous ensuite sur la page Actions de GitHub pour voir le résultat de la dernière exécution du workflow.

Comme vous le constatez, GitHub masque automatiquement la valeur de notre secret chiffré pour nous éviter de l’exposer par erreur.

Les secrets GitHub permettent de stocker des données sensibles, comme des mots de passe ou des clés d’autorisation d’API. Avec les secrets, il n’est pas nécessaire de coder en dur ces valeurs dans notre workflow et donc de les exposer à des entités externes. GitHub les chiffre, les transmet en toute sécurité aux actions de notre workflow et s’assure qu’elles n’apparaissent pas en clair ans les fichiers journaux.

Conclusion

Cet article s’est penché sur les variables d’environnement GitHub Actions Nous avons vu les trois portées possibles de ces variables (workflow, travail et étape), mais aussi la méthode à suivre pour définir des variables pour chacune de ces portées. Nous avons ensuite découvert comment utiliser les contextes pour transmettre des variables d’environnement à GitHub Actions et utiliser des secrets pour chiffrer des variables sensibles.

Les variables d’environnement GitHub Actions permettent aux développeurs de créer des workflows dynamiques. Elles donnent par exemple la possibilité de modifier le comportement d’un workflow sur la base d’une variable définie par l’utilisateur ou une variable par défaut de GitHub. Nous devons utiliser des variables dès lors que nous souhaitons modifier de manière dynamique le fonctionnement du workflow ou d’un travail ou d’une étape, mais aussi le moment auquel ils doivent être exécutés.

Cet article a également abordé l’utilisation des secrets GitHub sous forme de variables d’environnement pour protéger des informations sensibles. Il est important de penser à utiliser ces secrets pour les variables sensibles, comme les mots de passe et les clés API, car GitHub les chiffre et les injecte dans un workflow sans risque d’exposition.

N’oubliez pas, la sécurité avant tout ! Découvrez comment Snyk peut renforcer la sécurité de vos workflows GitHub et comment intégrer Snyk dans votre pipeline CI/CD pour assurer une sécurité exhaustive du code, des conteneurs, des dépendances open source et de l’IaC.