Git, Github et Github Actions - Maîtrise des Fondamentaux
Chapitre 4 - Maîtriser les Fondamentaux de GitHub Actions

Explorer GitHub Actions

Plan de formation

• Composants clés de GitHub Actions
• Triggers et Evénements
• Runners
• Avantages de l'intégration de GitHub Actions
• Configuration de base d'un workflow

Composants clés de GitHub Actions

Un workflow est une série de jobs qui s'exécutent dans GitHub Actions. Chaque job regroupe plusieurs steps, qui sont des actions ou des scripts individuels. Une action représente une unité autonome de code pouvant être réutilisée dans différents workflows.

Triggers et Evénements

Les triggers de workflow permettent de déclencher automatiquement des actions lors d'événements courants sur GitHub, tels que les push, les pull requests, la planification (schedule) ou l'exécution manuelle via workflow dispatch.

Runners

Les runners sont des machines qui exécutent les jobs définis dans vos workflows GitHub Actions. Ils peuvent être hébergés par GitHub ou auto-hébergés (self-hosted runners) par vous-même (Linux, Windows, macOS) pour plus de contrôle sur l'environnement d'exécution.

Avantages de l'intégration de GitHub Actions

GitHub Actions offre une intégration profonde avec GitHub, une grande flexibilité des workflows, ainsi qu'un support communautaire étendu et une marketplace riche en actions prêtes à l'emploi.

Configuration de base d'un workflow

Un fichier YAML pour GitHub Actions suit une structure spécifique et doit être placé dans le répertoire .github/workflows/ de votre dépôt. Si vous souhaitez créer des actions personnalisées, celles-ci doivent être placées dans le répertoire .github/actions/.

Décrire la structure et la syntaxe des fichiers YAML

Plan de formation

• Définition du format de fichier YAML
• Bases de la syntaxe YAML
• Types de données dans YAML
• Bonnes pratiques pour l'utilisation des types de données
• Ancres et Alias dans YAML
• Améliorations et fusion de dictionnaires

Définition du format de fichier YAML

YAML (YAML Ain't Markup Language) est un format de sérialisation de données lisible par l'homme, utilisé pour la configuration des fichiers dans divers outils, y compris GitHub Actions. Il utilise une syntaxe basée sur l'indentation pour représenter les structures de données telles que les listes et les dictionnaires.

Bases de la syntaxe YAML

La syntaxe YAML repose sur des éléments clés essentiels que les clés et valeurs, les listes (indiquées par des tirets) et les dictionnaires (indiqués par des paires clé-valeur). L'indentation est cruciale pour définir la hiérarchie des données.

Dans cet exemple, nous avons deux clés principales :

• Clé : settings
  • Type : Dictionnaire
  • Valeurs :
    • environnement: production
    • debug: true
• Clé : steps
  • Type : Liste
  • Valeurs :
    • setup: install dependencies
    • build: compile the project

Types de données dans YAML

Les nombres

Les nombres en YAML peuvent être représentés sous différentes formes, y compris les entiers (par exemple, 42), les nombres à virgule flottante (par exemple, 3.14), les nombres hexadécimaux (par exemple, 0x2A) et les nombres octaux (par exemple, 0o52). Ils sont utilisés pour représenter des valeurs numériques dans les fichiers YAML.

Les chaînes de caractères

Les chaînes de caractères en YAML peuvent être définies de plusieurs manières, notamment en utilisant des guillemets simples (') ou doubles ("), ou sans guillemets du tout. Les chaînes peuvent contenir des espaces, des caractères spéciaux et des sauts de ligne.

Les booléens

Les booléens en YAML représentent des valeurs de vérité, indiquant si une condition est vraie ou fausse. Ils sont définis par les valeurs true / yes / on ou false / no / off.

Les dictionnaires

Les dictionnaires en YAML sont des collections de paires clé-valeur, où chaque clé est associée à une valeur spécifique. Ils sont utilisés pour organiser les données de manière hiérarchique et sont représentés par des indentations.

Les listes

Les listes en YAML sont des collections ordonnées d'éléments, qui peuvent être de différents types (nombres, chaînes, dictionnaires, etc.). Elles sont indiquées par des tirets (-) suivis d'un espace.

Null

La valeur null peut être représentée par null, le symbole tilda ~ ou une chaîne vide.
Elle est utilisée pour indiquer l'absence de valeur ou une valeur non définie dans les fichiers YAML.

Bonnes pratiques pour l'utilisation des types de données

Pour garantir la clarté et la maintenance des fichiers YAML, il est recommandé de choisir un format adapté à votre projet pour chaque type de données et d'ajouter des commentaires pour expliquer les choix de configuration.

Ancres et Alias dans YAML

Les ancres et alias en YAML permettent de réutiliser des blocs de données. Une ancre est définie avec le symbole & et un alias avec le symbole *. Cela facilite la gestion des configurations répétitives.
L'ancre définit un bloc de données réutilisable, tandis que l'alias fait référence à cette ancre pour insérer le contenu défini ailleurs dans le fichier YAML.

Améliorations et fusion de dictionnaires

La fusion de dictionnaires en YAML permet de combiner plusieurs dictionnaires en un seul, en utilisant l'opérateur de fusion (<<:). Cela est utile pour hériter des configurations et éviter la duplication de données.

Dans cet exemple, le dictionnaire base est fusionné dans le dictionnaire development et production en utilisant l'opérateur de fusion. Cela permet à development et production d'hériter des valeurs de base, tout en pouvant ajouter ou modifier des clés spécifiques.

Si une clé existe à la fois dans le dictionnaire d'origine et dans le dictionnaire destination, la valeur du dictionnaire destination prendra le dessus.

Écrire un fichier YAML : Clés, Listes et Données

Plan de formation

• Démo : Ecriture d'un fichier YAML - partie 1

Démo : Ecriture d'un fichier YAML - partie 1

Dans cette démonstration, nous allons créer un fichier YAML sample.yaml avec un premier commentaire pour définir ce que le fichier contiendra.
Le commentaire dans YAML commence par le symbole #. Exemple :

# Exemple de fichier YAML

Ajout de Clés / Valeurs simples

Ensuite, nous allons ajouter des paires clé-valeur simples pour représenter des informations de configuration. Exemple :

# Clés / Valeurs simples (aussi appelé dictionnaire)
cle1: valeur1
cle2: valeur2

Création de listes

Nous allons maintenant créer une liste pour représenter une collection d'éléments. Exemple :

# Listes
liste_simple:
  - element1
  - element2
  - element3

Type de données

# Types de Données dans un fichier YAML
types_de_donnees:
  chaine: "Ceci est une chaîne de caractères"
  entier: 45
  flottant: 3.14
  boolean_vrai: true
  boolean_faux: false
  nul: null

Écrire un fichier YAML : Types Avancés, Ancres et Fusion

Plan de formation

• Démo : Ecriture d'un fichier YAML - partie 2

Démo : Ecriture d'un fichier YAML - partie 2

Les Nombres dans en détail

Nous allons approfondir la gestion des nombres dans YAML, en explorant les entiers, les flottants, les hexadécimaux et les octaux.
Exemple :

# Types de données numériques: Entiers, hexadécimaux, octaux
nombres:
  entier_decimal: 1234
  entier_hexadecimal: 0x4d2
  entier_octale: 02322

Les Chaînes

Nous allons explorer les chaînes de caractères dans YAML. Pour créer une chaîne de caractères multi-lignes, nous utilisons le symbole |.
Exemple :

# Chaînes, Booleans, Listes, et Nulls
divers:
  chaine_multi_ligne: |
    Ceci est une chaîne
    qui s'étend sur 
    plusieurs lignes.

Les Listes

Nous allons explorer les listes dans YAML. Pour créer une liste, nous utilisons un tiret - suivi d'un espace.
Exemple :

# Chaînes, Booleans, Listes, et Nulls
divers:
  liste:
  - item1
  - item2

Booléen et Nulls

Nous allons explorer les valeurs booléennes et nulles dans YAML.
Exemple :

# Booléens et Nulls
divers:
  boolean: true
  nul: null

Les Ancres et les Alias

Nous allons apprendre à utiliser les ancres et les alias pour réutiliser des blocs de données dans YAML. Dans l'exemple ci-dessous, nous définissons une ancre &ancre_base et &base. De cette manière, nous pouvons utiliser leur alias *ancre_base ainsi que *base pour réutiliser les données.
Exemple :

# Ancres et Alias
ancre_et_alias:
  &ancre_base
  base:
    nom: "Anass"
    age: 29
    ville: "Paris"

  copie_base: *ancre_base

# Fusion de Dictionnaires
fusion_dictionnaires:
  base: &base
    cle1: valeur1
    cle2: valeur2
  
  extension:
    <<: *base
    cle3: valeur3

Créer un Workflow Simple : Trigger et Job

Plan de formation

• Démo : Création d'un Workflow Simple

Démo : Création d'un Workflow Simple

Création de la Structure pour les Workflows

Pour commencer, il faut créer la structure de dossiers nécessaire pour héberger les fichiers de workflow GitHub Actions.
Nous allons créer un dossier nommé .github à la racine de notre dépôt, puis à l'intérieur de ce dossier, nous allons créer un sous-dossier nommé workflows.
Ensuite, nous allons créer un fichier YAML pour notre workflow simple, par exemple first-workflow.yml

# Structure des dossiers pour GitHub Actions
FORMATION-GITHUB-ACTIONS-CI-CD
├── .github
│   └── workflows
│       └── first-workflow.yml

Nom du Workflow

Pour commencer, il faut définir un nom pour le workflow qui sera affiché dans l'interface GitHub Actions. Si le nom n'est pas spécifié, GitHub utilisera le nom du fichier YAML par défaut.
Exemple :

name: first-workflow

Nom d'exécution du Workflow

Le Nom d'exécution est le nom qui sera affiché lors de l'exécution du workflow. Il peut être différent du nom du workflow. Ce nom apparaîtra dans l'interface utilisateur de GitHub Actions.
Exemple :

run-name: ${{ github.actor }} is learning GitHub Actions

Dans cet exemple, le nom d'exécution utilise une expression qui fait appel à la variable contextuelle github.actor. Celle-ci permet d'afficher le nom de l'utilisateur ayant déclenché le workflow. github est le contexte global, et actor est la propriété qui contient le nom de l'utilisateur.

Déclencheur du Workflow

Le Trigger du workflow définit l'événement qui va lancer l'exécution du workflow. Dans cet exemple, nous allons utiliser le déclencheur push, qui lance le workflow à chaque fois qu'un commit est poussé n'importe quelle branche.
Exemple :

on: [push]

Il est également possible de spécifier des branches spécifiques pour le déclencheur push, par exemple :

on:
  push:
  branches:
    - main
    - develop

Définition du Job

Un job est une série d'étapes (steps) qui s'exécutent sur un runner. Chaque job s'exécute dans son propre environnement et peut être configuré pour utiliser différents systèmes d'exploitation. Voici un exemple de définition d'un job nommé check-bat-version dans un fichier workflow GitHub Actions :

jobs:
  check-bat-version:
  runs-on: ubuntu-latest
  steps:
    - name: Vérifier la version de bat
      run: |
        bat --version

• check-bat-version: est le nom du job.
• runs-on: ubuntu-latest spécifie que le job s'exécutera sur une machine Ubuntu. Cette machine est fournie par GitHub en tant que runner hébergé.
• La section steps contient une étape unique qui exécute la commande bat --version pour afficher la version de l'outil bat.

Ce job check-bat-version s'exécutera sur un runner Ubuntu et affichera la version de l'outil bat (si installé) dans les logs du workflow.

Définir les Steps d'un Workflow Simple

Plan de formation

• Démo: Création d'un exemple de workflow
• Visualisation du fichier de workflow

Démo: Création d'un exemple de workflow

Création des Steps

Les steps (étapes) sont les actions individuelles qui composent un job dans un workflow GitHub Actions. Chaque step peut exécuter une commande, utiliser une action préexistante ou exécuter un script personnalisé.
Il faut definir les steps sous la forme de liste dans la section steps: d'un job.
Les noms des steps doivent être uniques au sein d'un même job pour éviter toute confusion lors de l'exécution du workflow.

Clé uses: actions/checkout@v5

La clé uses dans un fichier de workflow GitHub Actions est utilisée pour spécifier une action réutilisable à inclure dans une étape (step) d'un job.
Cette clé permet d'intégrer des actions préexistantes, soit celles fournies par GitHub, soit celles créées par la communauté et disponibles sur le GitHub Marketplace. C'est pourquoi, la valeur de la clé commence par actions/.
Voici un exemple d'utilisation de la clé uses dans un step :

steps:
  # Checkout the repository
  - name: Checkout repository
    uses: actions/checkout@v5

Dans cet exemple, le step utilise l'action actions/checkout@v5, qui est une action officielle de GitHub permettant de cloner le dépôt dans l'environnement du runner avant d'exécuter d'autres étapes.
La syntaxe actions/checkout@v4 indique que nous utilisons la version 4 de l'action checkout fournie par GitHub.

Pour plus d'informations sur cette action, vous pouvez consulter la documentation officielle :
github.com/actions/checkout

Clé uses: actions/setup-node@v6

La clé uses: actions/setup-node@v4 dans un fichier de workflow GitHub Actions est utilisée pour configurer l'environnement Node.js dans un job.
Cette action installe une version spécifique de Node.js sur le runner, ce qui est essentiel pour exécuter des applications ou des scripts Node.js.
Voici un exemple d'utilisation de cette action dans un step :

steps:
  # Set up Node.js environment 
  - name: Set up Node.js
    uses: actions/setup-node@v6
    with:
      node-version: '24'

Dans cet exemple, le step nommé "Setup Node.js" utilise l'action actions/setup-node@v4 pour installer la version 25 de Node.js sur le runner.
La section with: permet de spécifier des paramètres supplémentaires pour l'action, comme la version de Node.js à installer.

Pour plus d'informations sur cette action, vous pouvez consulter la documentation officielle :
github.com/actions/setup-node

Clé run: npm install -g bats

La clé run dans un fichier de workflow GitHub Actions est utilisée pour exécuter des commandes shell ou des scripts dans un step d'un job.
Cette clé permet d'exécuter des commandes directement sur le runner, ce qui est utile pour installer des dépendances, exécuter des tests, ou effectuer toute autre tâche nécessaire à l'automatisation du workflow.
Voici un exemple d'utilisation de la clé run dans un step :

steps:
  # Install Bats testing framework
  - name: Install Bats
    run: npm install -g bats

Dans cet exemple, le step nommé "Install Bats" utilise la clé run pour exécuter la commande npm install -g bats, qui installe l'outil de test Bats globalement sur le runner.
Cette commande est exécutée dans l'environnement shell du runner, permettant ainsi d'installer les dépendances nécessaires pour les étapes suivantes du workflow.

Clé run: bats -v

Voici un autre exemple d'utilisation de la clé run dans un step pour exécuter une commande de test :

steps:
  # Verify Bats installation
  - name: Check Bats version
    run: bats --version

Dans cet exemple, le step nommé "Run Bats version" utilise la clé run pour exécuter la commande bats -v, qui affiche la version de l'outil de test Bats installé sur le runner.
Cette commande est utile pour vérifier que Bats a été correctement installé et pour s'assurer que la bonne version est utilisée avant d'exécuter des tests supplémentaires.

Terminer le fichier Workflow

Une fois que toutes les étapes (steps) nécessaires ont été définies dans le job, il est important de vérifier la syntaxe du fichier YAML pour s'assurer qu'il est correctement formaté.
Après avoir validé la syntaxe, vous pouvez enregistrer le fichier et le pousser dans le dépôt GitHub.
Une fois le fichier poussé, GitHub Actions détectera automatiquement le nouveau workflow et l'exécutera en fonction du déclencheur (trigger) défini.

La bonne pratique est d'ajouter une ligne vide sans indentation ni espace à la fin du fichier YAML pour éviter d'éventuelles erreurs de parsing. C'est pour cela que l'exemple ci-dessous est plus grand qu'à l'habituel (balise <br> à la fin de la balise <pre>).
Voici un exemple de fichier YAML complet pour un workflow simple :

name: first-workflow
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
    # Checkout the repository
    - name: Checkout repository
      uses: actions/checkout@v5

    # Set up Node.js environment 
    - name: Set up Node.js
      uses: actions/setup-node@v6
      with:
        node-version: '24'

    # Install Bats testing framework
    - name: Install Bats
      run: npm install -g bats

    # Verify Bats installation
    - name: Check Bats version
      run: bats --version

Visualisation du fichier de workflow

Voilà à quoi va ressembler l'execution du workflow :

Exécuter un Workflow Simple

Plan de formation

• Démo : Exécution d'un Workflow

Démo : Exécution d'un Workflow

Pour exécuter un workflow simple dans GitHub Actions, il suffit de pousser un commit (Push) dans la branche spécifiée dans le déclencheur (trigger) du workflow.
Dans notre exemple précédent, le workflow est déclenché par un push sur n'importe quelle branche.
Voici les étapes pour exécuter le workflow :

1. Effectuez des modifications dans votre dépôt local et préparez un commit.
2. Poussez le commit vers le dépôt distant sur GitHub.
3. GitHub Actions détectera automatiquement le push et déclenchera l'exécution du workflow défini dans le fichier YAML.
4. Vous pouvez suivre l'exécution du workflow en accédant à l'onglet "Actions" de votre dépôt sur GitHub (cf image ci-dessous).

Afficher les détails d'un Workflow

Dans l'onglet Actions, menu gauche All workflows, une liste des workflows exécutés sera visible. En cliquant sur l'un d'eux, vous pouvez voir les détails de chaque exécution, y compris les logs des jobs et des steps.

En cliquant sur un job spécifique, vous pouvez voir les étapes (steps) qui ont été exécutées, ainsi que les logs associés à chaque étape. Cela vous permet de diagnostiquer les problèmes ou de vérifier que tout s'est déroulé comme prévu.
Il est également possible de relancer un workflow échoué en cliquant sur le bouton Re-run all jobs en haut à droite de la page des détails du workflow.

Découvrir les Jobs et Steps

Plan de formation

• Introduction aux Jobs et Steps
• Configuration de base d'un Job
• Configuration des Steps avancés

Introduction aux Jobs et Steps

Un Job est une série de steps (étapes), qui représentent des tâches ou des commandes individuelles exécutées séquentiellement dans le cadre d'un job. Chaque step peut exécuter une action spécifique, comme installer des dépendances, exécuter des tests ou déployer une application.

Configuration de base d'un Job

Pour configurer un job de base dans un workflow GitHub Actions, vous devez définir le nom du job unique, le système d'exploitation sur lequel il s'exécutera (runner), et les steps qu'il contiendra.
Voici un exemple de configuration de base d'un job :

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v5
      - name: Install dependencies
        run: npm install

Dans cet exemple, le job a l'ID unique build, un nom descriptif Build and Test, et s'exécute sur un runner Ubuntu. Il contient deux steps : l'un pour cloner le code du dépôt et l'autre pour installer les dépendances.

Configuration des Steps avancés

Les steps avancés permettent d'ajouter des options personnalisées pour contrôler l'exécution des tâches. Vous pouvez utiliser des conditions (if), des secrets pour sécuriser les données sensibles, et des paramètres spécifiques aux actions.

steps:
  - name: Checkout code
    uses: actions/checkout@v5

  - name: Setup Node.js
    uses: actions/setup-node@v6
    with:
      node-version: '24'

  - name: Run custom script
    run: node custom-script.js
    working-directory: scripts
    shell: bash
    env:
      CUSTOM_ENV_VAR: value

Analyser la Communication et la Gestion des Jobs et Steps

Plan de formation

• Communication entre Jobs et Steps
• Utilisation des Variables d'environnement
• Configuration par défaut
• Gestion des erreurs et délais d'exécution

Communication entre Jobs et Steps

Dans l'exemple ci-dessous, nous avons deux jobs : setup et build. Le job setup exécute une étape qui définit une sortie nommée result. Cette sortie est ensuite utilisée comme entrée dans le job build via la syntaxe $.
Voici comment cela fonctionne :

jobs:
  setup:
    runs-on: ubuntu-latest
    outputs:
      data: ${{ steps.setup.outputs.result }}
    steps:
      - name: Setup environment
        id: setup
        run: echo "::set-output name=result::success"

  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - name: Use setup data
        # The problem is with the YAML syntax where the nested mapping is not properly formatted for the compact style.
        run: "echo 'Using data from setup: ${{ needs.setup.outputs.data }}'"

Le but de cet exemple est de montrer comment un job peut dépendre d'un autre et comment les données peuvent être transmises entre eux. Le job build attend que le job setup soit terminé avant de s'exécuter, et utilise la sortie du job setup dans son propre step.

L'output data du job setup se définit en utilisant la syntaxe ${{ steps.setup.outputs.result }}, où steps.setup.outputs.result fait référence à la sortie définie dans le step avec l'ID setup.
Cette sortie est ensuite accessible dans le job build via la syntaxe ${{ needs.setup.outputs.data }}, permettant ainsi au job build d'utiliser les données générées par le job setup.

Dans le job build, une dépendance est créée avec le job setup en utilisant la clé needs: setup. Cela garantit que le job build ne s'exécutera qu'après la réussite du job setup.

${{ steps.job-id.outputs.output-name }}

${{ needs.job-id.outputs.output-name }}

Utilisation des Variables d'environnement

Les variables d'environnement permettent de transmettre des informations entre les steps d'un job ou de configurer l'environnement d'exécution. Elles peuvent être définies au niveau du workflow, du job ou du step, et sont accessibles via la syntaxe ${{ env.VARIABLE_NAME }}.

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      GLOBAL_ENV: production # Variable d'environnement globale pour le job accessible à tous les steps
    steps:
      - name: checkout code
        uses: actions/checkout@v5

      - name: Install dependencies
        run: npm install

      - name: run script with environment variables
        run: echo "The environment is $GLOBAL_ENV AND LOCAL VAR IS $LOCAL_ENV"
        env:
          LOCAL_ENV: specific-task # Variable locale uniquement pour ce step

Configuration par défaut

La configuration par défaut dans GitHub Actions inclut les paramètres globaux qui s'appliquent à tous les jobs et steps d'un workflow, tels que le shell par défaut, le répertoire de travail, et les variables d'environnement communes. Ces configurations peuvent être redéfinies au niveau du job ou du step si nécessaire.

jobs:
  test:
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
        working-directory: /path/to/directory
    steps:
      - name: Execute script
        run: ./test-script.sh

Gestion des erreurs et délais d'exécution

GitHub Actions propose plusieurs mécanismes pour gérer les erreurs et contrôler les délais d'exécution, notamment les options continue-on-error pour poursuivre l'exécution malgré les échecs, timeout-minutes pour limiter la durée d'exécution, et les stratégies de retry pour relancer automatiquement les jobs échoués.

steps:
  - name: Long running test
    run: ./run-long-test.sh
    continue-on-error: true # Continue même si ce step échoue
    timeout-minutes: 15 # Limite le temps d'exécution à 15 minutes

Utiliser Jobs et Steps : Création des Fichiers

Plan de formation

• Démo : Build et Test d'un script JavaScript simple - partie 1

Démo : Build et Test d'un script JavaScript simple - partie 1

Création des Fichiers

Pour cette démo, nous allons créer deux fichiers : un fichier JavaScript simple nommé index.js et un fichier de test nommé test.js dont voici leur contenu :

// index.js
function greet() {
  return "Hello, World!";
}

module.exports = greet;

// test.js
const greet = require('./index');

console.log("Running test...");

if (greet() === "Hello, World!") {
  console.log("Test passed!");
  process.exit(0);
} else {
  console.log("Test failed!");
  process.exit(1);
}

Nous avons également besoin d'un fichier package.json pour gérer les dépendances et les scripts npm. Voici un exemple de contenu pour ce fichier :

{
  "name": "simple-node-app",
  "version": "1.0.0",
  "description": "A simple Node.js application",
  "main": "index.js",

  "scripts": {
    "test": "node test.js",
    "build": "echo 'Building... Nothing to compile!'"
  },
  "author": "Your Name",
  "license": "ISC"
}

Création du Workflow Build and Test

Maintenant, nous allons créer un fichier de workflow GitHub Actions nommé build-and-test.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Node.js Build and Test

on:
  push:
    branches: [main]
  pull_request: 
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test

Utiliser Job et Steps : Push et Exécuter

Plan de formation

• Démo : Build et Test d'un script JavaScript simple - partie 2

Démo : Build et Test d'un script JavaScript simple - partie 2

Pour commencer, il faut faire le commit et poussez les fichiers créés précédemment dans le dépôt GitHub.

Commit et Push des Fichiers

Pour le commit, il est possible d'utiliser une syntaxe Markdown dans le message de commit pour référencer les fichiers modifiés.
Voici un exemple de message de commit :

`index.js` and `test.js` and `package.json` and `build-and-test-nodejs.yml`
Add build and test nodejs workflow

Il ne reste plus qu'à pousser le commit vers la branche principale (main) du dépôt distant sur GitHub.

Exécution du Workflow

Une fois le commit poussé, GitHub Actions détectera automatiquement le push et déclenchera l'exécution du workflow défini dans le fichier YAML.
Vous pouvez suivre l'exécution du workflow en accédant à l'onglet "Actions" de votre dépôt sur GitHub comme décrit précédemment.

Tester un Script Python avec Jobs et Steps

Plan de formation

• Démo : Exécution d'un script Python

Démo : Exécution d'un script Python

Pour commencer, nous allons créer un fichier Python simple nommé is_prime.py qui vérifie si un nombre est premier ou non. Voici le contenu du fichier :

import sys

def is_prime(n):
    """Return True if n is a prime number, else False."""
    if n < 2:
        return False
    for i in range(2, int(n ** 0.5) + 1):
        if n % i == 0:
            return False
    return True

if __name__ == "__main__":
    number = int(sys.argv[1])
    if is_prime(number):
        print(f"{number} is a prime number.")
    else:
        print(f"{number} is not a prime number.")

Maintenant, nous allons créer un fichier de workflow GitHub Actions nommé execute-python-script.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Python Script Execution

on: [push]

jobs:
  check_prime:
    runs-on: ubuntu-latest

    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Python environment
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'

      # Install dependencies
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install virtualenv
          virtualenv venv
          source venv/bin/activate

      # Run the Python script
      - name: Run Python script
        run: python is_prime.py 29 # Example with number 29

Expliquer les Conditions et Syntaxe de Base

Plan de formation

• Introduction aux conditions
• Syntaxe de base des conditions

Introduction aux conditions

Les conditions dans GitHub Actions permettent de contrôler l'exécution des jobs et des steps en fonction de critères spécifiques. Elles sont définies à l'aide de la clé if et peuvent évaluer des expressions logiques pour déterminer si un job ou un step doit s'exécuter ou non.
Les conditions peuvent être basées sur divers facteurs, tels que le résultat d'un job précédent, la branche sur laquelle le workflow est déclenché, ou des variables d'environnement.

Syntaxe de base des conditions

L'exemple suivant montre comment utiliser une condition simple pour exécuter un job uniquement si la branche est main :

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' # Exécute ce job uniquement si la branche est 'main'
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: build
        run: echo "Building because this is the main branch!"

Utiliser les Conditions Avancées

Plan de formation

• Utiliser les résultats des étapes précédentes
• Conditions avancées avec fonctions

Utiliser les résultats des étapes précédentes

Avec la clé needs, il est possible de faire dépendre un job d'un autre et d'utiliser son résultat pour déterminer si le job actuel doit s'exécuter.
L'exemple suivant montre comment exécuter un job de déploiement uniquement si le job de test précédent a réussi et si la branche est main :

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: exit 1 # Simulate a test failure

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && success()
    runs-on: ubuntu-latest
    steps:
      - name: Deploy 
        run: echo "Deploying application..."
      

Conditions avancées avec fonctions

Voilà une liste de fonctions utiles pour les conditions avancées :

• success() : Retourne vrai si tous les jobs précédents ont réussi.
• failure() : Retourne vrai si un job précédent a échoué.
• always() : Retourne vrai quel que soit le résultat des jobs précédents.
• cancelled() : Retourne vrai si un job précédent a été annulé.

L'exemple suivant montre comment utiliser la fonction always() pour exécuter un job de nettoyage, quel que soit le résultat des jobs précédents :

jobs:
  cleanup:
    if: always()
    runs-on: ubuntu-latest
    steps:
      - name: Cleanup resources
        run: echo "Cleaning up resources..."

Appliquer les Conditions Basées sur les Branches

Plan de formation

• Démo : Utilisation des conditions basées sur les branches

Démo : Utilisation des Conditions Basées sur les Branches

Pour commencer, nous allons créer une copie du fichier build-and-test-nodejs.yml afin de conserver l'historique de la formation.
Nous allons nommer ce nouveau fichier jobs-with-conditions.yml et y ajouter des conditions basées sur les branches pour contrôler l'exécution des jobs de build et de test.
Voici le contenu modifié du fichier avec les conditions ajoutées :

name: Node.js Build and Test

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'  # Exécute ce job uniquement si la branche est 'main'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'  # Exécute ce job uniquement si la branche est 'main'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test

Ceci étant fait, nous allons créer une nouvelle branche nommée feat/test-conditions-in-workflow pour tester les conditions basées sur les branches.
Après avoir poussé cette branche, nous allons vérifier l'onglet Actions dans le dépôt GitHub pour voir si les jobs de build et de test ont été exécutés ou non.

Création de la Pull Request

Maintenant, nous allons créer une pull request pour fusionner la branche feat/test-conditions-in-workflow dans la branche principale main.
Après avoir créé la pull request, nous allons vérifier à nouveau l'onglet Actions dans le dépôt GitHub pour voir si les jobs de build et de test ont été exécutés cette fois-ci.

Dans le prochain chapitre, nous allons voir pourquoi la pull request n'a pas déclenché l'exécution des jobs de build et de test.

Résoudre les Erreurs des Conditions Basées sur les Branches

Plan de formation

• Démo : Résolution des erreurs des conditions basées sur les branches

Démo : Résolution des erreurs des Conditions Basées sur les Branches

Le problème avec les conditions basées sur les branches dans notre workflow précédent est que nous avons utilisé la condition if: github.ref == 'refs/heads/main' pour les jobs de build et de test.
Cette condition vérifie uniquement si la référence GitHub correspond exactement à la branche main, ce qui n'est pas le cas lors d'une pull request, car la référence sera quelque chose comme refs/pull/ID/merge.
Pour résoudre ce problème, nous devons modifier les conditions pour qu'elles prennent en compte à la fois les pushs directs sur la branche main et les pull requests vers cette branche.
Voici comment nous pouvons modifier les conditions dans le fichier jobs-with-conditions.yml :

name: Node.js Build and Test with conditions

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.base_ref == 'main'  # Exécute ce job uniquement si la branche de base est 'main' (utile pour les pull requests)
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    if: github.base_ref == 'main'  # Exécute ce job uniquement si la branche de base est 'main' (utile pour les pull requests)
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test

Préparation pour la Nouvelle Pull Request

Avant de pouvoir faire une nouvelle pull request, nous devons d'abord clôturer l'ancienne pull request.
Pour ce faire, il faut aller dans l'onglet "Pull requests" du dépôt GitHub, sélectionner la pull request existante, puis cliquer sur le bouton "Close pull request".

Ensuite, il suffit de faire le commit des modifications apportées au fichier jobs-with-conditions.yml et de pousser ces modifications vers la branche feat/test-conditions-in-workflow.
Après cela, nous pouvons créer une nouvelle pull request pour fusionner les modifications dans la branche principale main.

Création de la Nouvelle Pull Request

Une fois la nouvelle pull request créée, nous allons vérifier l'onglet Actions dans le dépôt GitHub pour voir si les jobs de build et de test ont été exécutés cette fois-ci.

Appliquer les Conditions Basées sur les Triggers (push & pull)

Plan de formation

• Démo : Utilisation des conditions basée sur les triggers

Démo : Utilisation des Conditions Basée sur les Triggers

Pour cette démo, nous allons créer un nouveau fichier de workflow nommé jobs-trigger-conditions.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Jobs trigger conditions

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' || github.event_name == 'pull_request'  # Exécute ce job uniquement pour les événements 'push' et 'pull_request'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' || github.event_name == 'pull_request'  # Exécute ce job uniquement pour les événements 'push' et 'pull_request'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test


  deploy:
    runs-on: ubuntu-latest
    if: (github.event_name == 'push' && github.refs == 'refs/heads/main') || github.event_name == 'workflow_dispatch'  # Exécute ce job uniquement pour les événements 'push' et 'workflow_dispatch'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Deploy
        run: npm run deploy

Utiliser les Conditions Basées sur les Triggers Suite (workflow_dispatch)

Plan de formation

• Démo : Utilisation des conditions basée sur les triggers (workflow_dispatch)

Démo : Utilisation des Conditions Basée sur les Triggers (workflow_dispatch)

Pour commencer, nous allons fusionner la pull request précédente afin d'intégrer les modifications dans la branche principale main. Cela va créer un nouvel événement de push sur la branche main.

Il est également possible de déclencher manuellement le workflow en utilisant le trigger workflow_dispatch.
Pour ce faire, il faut aller dans l'onglet "Actions" du dépôt GitHub, sélectionner le workflow nommé "Jobs trigger conditions", puis cliquer sur le bouton "Run workflow". Il est possible de choisir pour quelle branche le workflow doit être exécuté.

Une fois le workflow déclenché, nous pouvons vérifier l'onglet Actions pour voir l'état d'exécution des jobs. Dans ce cas, le job de déploiement s'exécute avec une erreur car le script "deploy" n'est pas défini dans le fichier package.json. Cela peut être vu dans les logs du job de déploiement.

Appliquer les Conditions Basées sur les Fonctions

Plan de formation

• Démo : Utilisation des conditions basée sur les fonctions Github

Démo : Utilisation des Conditions Basée sur les Fonctions Github

Pour cette démo, nous allons créer un nouveau fichier de workflow nommé workflow-functions.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Workflow with functions

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    if: contains(fromJson('["push", "pull_request"]'), github.event_name)  # Exécute ce job uniquement pour les événements 'push' et 'pull_request'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    if: contains(fromJson('["push", "pull_request"]'), github.event_name)  # Exécute ce job uniquement pour les événements 'push' et 'pull_request'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test


  deploy:
    runs-on: ubuntu-latest
    if: (github.event_name == 'push' && github.ref == 'refs/heads/main') || github.event_name == 'workflow_dispatch'  # Exécute ce job uniquement pour les événements 'push' et 'workflow_dispatch'
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Deploy
        run: npm run deploy

      - name: Run if deploy was successful
        if: ${{ success() }}
        run: echo "The deploy job was run successfully"

En observant les logs d'exécution du workflow, nous pouvons voir que les jobs de build et de test s'exécutent correctement pour les événements de push et de pull request.
Le job de déploiement s'exécute également, mais échoue en raison de l'absence du script "deploy" dans le fichier package.json.
Cependant, le step "Run if deploy was successful" ne s'exécute pas car le job de déploiement a échoué, ce qui est conforme à la condition définie avec la fonction success().

Si l'on change de success() à failure(), nous pouvons voir que le step "Run if deploy was successful" s'exécute cette fois-ci, car le job de déploiement a échoué.

Cela démontre comment utiliser les fonctions dans les conditions pour contrôler l'exécution des jobs et des steps dans un workflow GitHub Actions.

Configurer des Triggers et Planifier des Jobs

Plan de formation

• Déclencheurs de workflows standards
• Déclencheurs pour la collaboration et la gestion des problèmes
• Planification des workflows avec CRON
• Déclencheurs avancés et intégrations
• Réagir aux événements externes

Déclencheurs de workflows standards

Les déclencheurs de workflows standards dans GitHub Actions incluent des événements courants tels que push, pull_request, et workflow_dispatch.
Ces déclencheurs permettent de lancer des workflows automatiquement en réponse à des actions spécifiques dans le dépôt, comme lorsqu'un code est poussé ou lorsqu'une pull request est créée ou mise à jour.
Voici un exemple de configuration YAML utilisant les déclencheurs push et pull_request :

on:
  push:
    branches: [ 'main', 'develop']
    paths: [ 'src/**/*', 'docs/**/*' ]
  pull_request:
    types: [ opened, synchronize, reopened ]	

Dans cet exemple, le workflow sera déclenché pour les pushs sur les branches main et develop avec pour condition supplémentaire que les fichiers doivent se trouver dans les dossiers 'src' ou 'docs', ainsi que pour les pull requests qui sont ouvertes, synchronisées ou rouvertes.

Déclencheurs pour la collaboration et la gestion des problèmes

GitHub Actions offre une variété de déclencheurs liés à la collaboration et à la gestion des problèmes, tels que issues, issue_comment, pull_request_review, et project_card.
Ces déclencheurs permettent d'automatiser les workflows en réponse à des actions spécifiques liées aux problèmes, aux commentaires, aux revues de pull request, et aux cartes de projet.
Voici un exemple de configuration YAML utilisant le déclencheur issues :

on:
  issues:
    types: [opened, edited, closed]
  issue_comment:
    types: [created, edited, deleted]

Planification des workflows avec CRON

GitHub Actions permet de planifier des workflows à l'aide de la syntaxe CRON, ce qui permet d'exécuter des tâches à des intervalles réguliers.
Voici un exemple de configuration YAML utilisant la planification CRON pour exécuter un workflow tous les jours à minuit UTC :

on:
  schedule:
    - cron: '0 0 * * *'  # Tous les jours à minuit UTC
    # Syntaxe cron: minute / heure / jour_du_mois / mois / jour_de_la_semaine
    # minute (0-59)
    # heure (0-23)
    # jour_du_mois (1-31)
    # mois (1-12)
    # jour_de_la_semaine (0-6, où 0 = dimanche)
    # 
    # Caractères spéciaux:
    # * = toutes les valeurs
    # 0 = valeur spécifique (ex: 0 pour minute = à la minute 0)

Déclencheurs avancés et intégrations

GitHub Actions prend en charge des déclencheurs avancés tels que workflow_call et workflow_run, qui permettent d'intégrer des workflows entre différents dépôts.

workflow_call permet à un workflow d'appeler un autre workflow, tandis que workflow_run permet de déclencher un workflow en fonction du résultat d'un autre workflow.

on:
  workflow_call:
  workflow_run:
    workflows: ["CI Build"]
    types:
      - completed

Réagir aux événements externes

repository_dispatch permet de déclencher des workflows en réponse à des événements externes via l'API GitHub.
Voici un exemple de configuration YAML utilisant le déclencheur workflow_call et workflow_run :

on:
  repository_dispatch:
    types: [ trigger-action ]
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Set the log level'
        required: true
        default: 'warning'

workflow_dispatch permet également de définir des entrées personnalisées pour le workflow, comme illustré dans l'exemple ci-dessus avec l'entrée logLevel.

Utiliser les Triggers de Workflow Standards (pull request)

Plan de formation

• Démo : Utilisation des triggers de workflow standards

Démo : Utilisation des Triggers de Workflow Standards

Pour cette démo, nous allons créer un nouveau fichier de workflow nommé triggers-workflow-standard.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Trigger workflow standard

on:
  pull_request:
    types: 
      - opened
      - reopened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test

Dans cet exemple, le workflow sera déclenché pour les pull requests qui sont ouvertes ou rouvertes, ciblant les branches correspondant au motif 'releases/**' et affectant des fichiers JavaScript (**.js).
Les jobs de build et de test s'exécuteront en conséquence lorsque ces conditions seront remplies.

Configurer les Triggers de Workflow Standards (push)

Plan de formation

• Démo : Suite de l'utilisation des triggers de workflow standards
• Démo : Planifier des jobs avec cron

Démo : Suite de l'utilisation des Triggers de Workflow Standards

if: startsWith(github.head_ref, 'test')

Démo : Planifier des Jobs avec CRON

Le cron (clé schedule) s'exécute uniquement sur la branche par défaut. Pour connaître la branche par défaut, il faut aller dans les paramètres du dépôt GitHub, puis dans l'onglet "Branches".

Si nous souhaitons planifier un job sur plusieurs jours, il faut utiliser le séparateur virgule dans le champ correspondant du cron.
Par exemple, pour exécuter un job tous les lundis et mercredis à 2h du matin, nous utiliserons la syntaxe suivante :

on:
	schedule:
		- cron: '0 2 * * 1,3'  # Tous les lundis et mercredis à 2h du matin UTC

Il est possible de planifier plusieurs exécutions en ajoutant plusieurs entrées sous la clé schedule.
Dans l'exemple suivant, le workflow est configuré pour s'exécuter toutes les minutes ainsi qu'à 3h30 du matin chaque samedi et dimanche :

name: Schedule Cron Jobs

on:
  schedule:
    - cron: '* * * * *'  # Runs every minute
    - cron: '30 3 * * 0,6'  # Runs at 3:30 AM every Saturday and Sunday

Planifier les Jobs (suite et exécution)

Plan de formation

• Démo : Suite de la planification des jobs avec cron

Démo : Suite de la planification des Jobs avec CRON

Nous allons faire le teste sur la base du fichier schedule-cron-jobs.yml que nous avons créé précédemment dont voici le contenu :

name: Schedule Cron Jobs

on:
  schedule:
    - cron: '* * * * *'  # Runs every minute
    - cron: '30 3 * * 0,6'  # Runs at 3:30 AM every Saturday and Sunday

jobs:
  test_scheduled:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Saturday or Sunday
        if: github.event.schedule != '30 3 * * 0,6'
        run: echo "This step will be skipped on Saturday and Sunday."
      
      - name: Every time step
        run: echo "This step runs every minute all days."

Configurer le Trigger workflow_run

Plan de formation

• Démo : Utilisation du trigger workflow_run

Démo : Utilisation du Trigger workflow_run

Le trigger workflow_run permet de déclencher un workflow lorsqu'un autre workflow spécifique se termine dans le même dépôt. Il est utile pour enchaîner des workflows, par exemple pour exécuter des tests après un build ou effectuer un déploiement après la réussite d'un workflow de CI.

Pour notre exemple, nous allons utiliser le workflow execute-python-script.yml ainsi qu'un nouveau workflow nommé workflow-run-job.yml dont voici le contenu :

name: Trigger workflow run

on:
  pull_request:
    types: 
      - opened
      - reopened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

  workflow_run:
    workflows: ["Python Script Execution"]
    types:
      - completed

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      # Install dependencies
      - name: Install dependencies
        run: npm install
        
      # Run build
      - name: Build
        run: npm run build

  test:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v5

      # Set up Node.js environment 
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # Run tests
      - name: Run tests
        run: npm run test

Dans cet exemple, le workflow workflow-run-job.yml sera déclenché pour les pull requests ouvertes ou rouvertes ciblant les branches correspondant au motif 'releases/**' et affectant des fichiers JavaScript (**.js).
De plus, il sera également déclenché lorsque le workflow nommé "Python Script Execution" se termine, quel que soit son résultat (succès ou échec).

Utiliser le Trigger workflow_dispatch

Plan de formation

• Démo : Utilisation du trigger workflow_dispatch

Démo : Utilisation du Trigger workflow_dispatch

Le trigger workflow_dispatch permet de déclencher manuellement un workflow via l'interface utilisateur de GitHub ou via l'API GitHub.
Cela est utile pour exécuter des workflows à la demande, par exemple pour des déploiements manuels ou des tests spécifiques.

Pour cette démo, nous allons créer un nouveau fichier de workflow nommé workflow-dispatch-job.yml dans le dossier .github/workflows/ avec le contenu suivant :

name: Workflow Dispatch Job
on:
  workflow_dispatch:
    inputs:
      logLevel: 
        description: "Log level"
        required: true
        default: "warning"
        type: choice
        options:
        - "debug"
        - "info"
        - "warning"

      tags:
        description: "Test scenario tags"
        required: false
        type: boolean

      environment:
        description: "Environment to run tests against"
        type: choice
        options:
        - "staging"
        - "preprod"
        - "prod"
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

Il est ensuite possible de déclencher manuellement le workflow en utilisant le trigger workflow_dispatch.
Pour ce faire, il faut aller dans l'onglet "Actions" du dépôt GitHub, sélectionner le workflow nommé "Workflow Dispatch Job", puis cliquer sur le bouton "Run workflow" est de définir les valeurs requises pour les inputs.