Implémenter des variables et des scripts dans un workflow

Effectué

Maintenant que vous connaissez les composants d’un fichier de flux de travail, découvrez comment personnaliser ces flux de travail pour différents scénarios. Dans cette unité, nous allons nous concentrer sur l’utilisation de variables et de scripts pour optimiser le flux de travail. Les variables fournissent un moyen 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 l’ordinateur exécuteur qui exécute votre workflow. Les commandes qui s’exécutent dans des actions ou des étapes de flux de travail peuvent créer, lire et modifier des variables.

Vous pouvez définir vos propres variables personnalisées ou utiliser les variables d’environnement par défaut définies automatiquement par GitHub. Vous pouvez créer une variable personnalisée de deux façons.

• Pour définir une variable d’environnement à utiliser dans un seul flux de travail, vous pouvez utiliser la clé env dans le fichier de flux de travail.
• Pour définir une variable de configuration sur plusieurs flux de travail, vous pouvez la définir au niveau de l’organisation, du référentiel ou de l’environnement.

Définir des variables d’environnement pour un seul workflow

Pour définir une variable d’environnement personnalisée pour un flux de travail unique, vous pouvez la définir à l’aide de la clé env dans le fichier de flux de travail. L’étendue d’une variable personnalisée définie par cette méthode est limitée à l’élément où elle est définie. Vous pouvez définir des variables qui sont délimitées pour :

• Le flux de travail entier, en utilisant env au niveau supérieur du fichier de workflow.
• Étendre le contenu d’une tâche dans un flux de travail, réalisé grâce à jobs.<job_id>.env.
• Une étape spécifique dans un travail, à l’aide de jobs.<job_id>.steps[*].env.

Remarque

Les jobs.<job_id>.env et les jobs.<job_id>.steps[*].env implémentent des contextes abordés plus loin dans ce module.

L’exemple de flux de travail suivant implémente deux variables, DAY_OF_WEEK et Greeting pour produire un message d’accueil lors de son exécution.

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"
        run: echo "$Greeting, today is $DAY_OF_WEEK!"

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 variables d’environnement par défaut. Si vous tentez de remplacer la valeur de l’une de ces variables par défaut, l’affectation est ignorée.

Conseil

Pour obtenir la liste complète des variables d’environnement par défaut, visitez variables d’environnement par défaut.

Créer des variables de configuration pour un référentiel

Pour créer des secrets ou des variables sur GitHub pour un dépôt 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 dépôt d'organisation, vous devez disposer d'un accès admin. Enfin, pour créer des secrets ou des variables pour un dépôt de compte personnel ou un référentiel d’organisation via l’API REST, vous devez disposer d’un accès collaborateur.

Priorité des variables de configuration

Si une variable portant le même nom existe à 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 référentiel, la variable au niveau du référentiel est prioritaire. De même, si une organisation, un référentiel et un environnement ont toutes une variable portant le même nom, la variable au niveau de l’environnement est prioritaire.

Ajouter des scripts à votre workflow

Vous pouvez utiliser un workflow GitHub Actions pour exécuter des scripts et des commandes shell, qui sont ensuite exécutées sur l’exécuteur affecté. L’exemple suivant montre comment utiliser le mot-clé run pour exécuter la commande npm install -g bats sur l’exécuteur.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - run: npm install -g bats

Pour exécuter un script stocké dans votre référentiel, vous devez d’abord extraire le référentiel sur l’exécuteur. L’exemple suivant : extrait le référentiel ; définit le répertoire de travail : emplacement des scripts dans le référentiel ; et exécute le script my-script.sh.

jobs:
  example-job:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./scripts
    steps:
      - name: Check out the repository to the runner
        uses: actions/checkout@v4  
      - name: Run a script
        run: ./my-script.sh

Tous les scripts que vous souhaitez exécuter un travail de workflow doivent être exécutables. Vous pouvez transmettre le script en tant qu’argument à l’interpréteur qui exécute le script ( par exemple, run: bash script.sh) ou en rendant le fichier lui-même exécutable.