Dépendances de Tâches GitHub Actions - Build et Déploiement

Introduction

Dans les pipelines CI/CD du monde réel, les workflows sont rarement une simple liste d'étapes. Ils sont souvent composés de plusieurs "tâches" (jobs) distinctes qui doivent s'exécuter dans un ordre spécifique.

Par exemple, vous pourriez avoir une tâche Build qui compile votre code, et une tâche Deploy qui le pousse vers un serveur. Vous ne voulez absolument pas que la tâche Deploy s'exécute si la tâche Build échoue, et vous ne pouvez pas les exécuter en même temps car le déploiement nécessite les artefacts construits.

Dans ce laboratoire, vous allez diviser votre workflow en deux tâches distinctes et utiliser le mot-clé needs pour imposer une dépendance, garantissant que la tâche de déploiement attend que la tâche de construction se termine avec succès.

Ce laboratoire s'appuie sur le dépôt que vous avez créé lors des laboratoires précédents. Vous travaillerez avec le dépôt github-actions-demo.

Définir une tâche de construction (build)

Nous allons d'abord nettoyer notre workflow existant pour avoir un job build ciblé. Nous simplifierons la stratégie de matrice du laboratoire précédent pour plus de clarté, en revenant à une seule version pour nous concentrer sur les dépendances des jobs.

Sur la page de votre dépôt GitHub pour github-actions-demo, cliquez sur le bouton vert Code.
Assurez-vous que l'onglet HTTPS est sélectionné et copiez l'URL. Elle devrait ressembler à https://github.com/your-username/github-actions-demo.git.
Ouvrez le terminal dans l'environnement LabEx. Le chemin par défaut est ~/project.
Utilisez la commande git clone pour télécharger le dépôt. Remplacez your-username par votre nom d'utilisateur GitHub réel.

cd ~/project
git clone https://github.com/your-username/github-actions-demo.git

Exemple de sortie :

Cloning into 'github-actions-demo'...
remote: Enumerating objects: X, done.
remote: Counting objects: 100% (X/X), done.
remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (X/X), done.

Naviguez dans le dépôt cloné :

cd ~/project/github-actions-demo

Créez un nouveau fichier de workflow .github/workflows/job-dependencies.yml en utilisant l'éditeur WebIDE. Vous pouvez trouver le fichier dans l'explorateur de fichiers sur le côté gauche sous project/github-actions-demo/.github/workflows/.
Commencez par créer la structure de workflow de base. Ajoutez le nom du workflow et le déclencheur :

name: Job Dependencies

on: [push]

Ajoutez la section jobs et définissez le job build avec son exécuteur (runner) :

jobs:
  build:
    runs-on: ubuntu-latest

Ajoutez la section steps. Tout d'abord, ajoutez l'étape de checkout pour récupérer le code du dépôt :

steps:
  - uses: actions/checkout@v4

Ajoutez l'étape de configuration de Node.js :

- name: Use Node.js
  uses: actions/setup-node@v4
  with:
    node-version: "20"

Ajoutez l'étape pour installer les dépendances :

- name: Install dependencies
  run: npm install

Ajoutez l'étape pour exécuter les tests :

- name: Run tests
  run: npm test

Ajoutez l'étape de construction (build) qui crée le répertoire d'artefacts et le fichier :

- name: Build project
  run: |
    mkdir dist
    echo "Build artifact created at $(date)" > dist/build.txt

Enfin, ajoutez l'étape de téléchargement de l'artefact (Upload artifact). Cette étape est cruciale car elle sauvegarde la sortie de la construction afin que le job suivant puisse l'utiliser :

- name: Upload build artifact
  uses: actions/upload-artifact@v4
  with:
    name: dist-files
    path: dist

Votre fichier complet devrait maintenant ressembler à ceci :

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

Explication

Nous avons supprimé la stratégie matrix pour simplifier.
Nous avons conservé l'étape Upload build artifact. C'est crucial car le job suivant aura besoin de ces fichiers !

Enregistrez le fichier (Ctrl+S ou Cmd+S) après avoir effectué les modifications.

Définir une tâche de déploiement (deploy) qui dépend de build

Nous allons maintenant ajouter une deuxième tâche nommée deploy. Cette tâche ne doit s'exécuter que si build réussit. Nous y parvenons en utilisant needs: build.

Ajoutez la tâche deploy suivante à votre fichier .github/workflows/job-dependencies.yml. Assurez-vous qu'elle se trouve au même niveau d'indentation que build.
Commencez par ajouter la définition de la tâche de déploiement avec son exécuteur (runner) et sa dépendance :

deploy:
  runs-on: ubuntu-latest
  needs: build

La ligne needs: build est cruciale : elle indique à GitHub Actions que cette tâche dépend de la complétion réussie de la tâche build.

Ajoutez la section des étapes (steps). Tout d'abord, ajoutez l'étape pour télécharger l'artefact :

steps:
  - name: Download artifact
    uses: actions/download-artifact@v4
    with:
      name: dist-files
      path: dist

Ceci télécharge l'artefact qui a été téléversé lors de la tâche build. Le name doit correspondre au nom utilisé dans l'étape de téléversement.

Ajoutez l'étape de déploiement :

- name: Deploy project
  run: |
    echo "Deploying project..."
    ls -R dist
    echo "Deployment successful!"

Cette étape simule un déploiement en listant les fichiers téléchargés.

La structure complète de votre fichier devrait ressembler à ceci :

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v4
        with:
          name: dist-files
          path: dist
      - name: Deploy project
        run: |
          echo "Deploying project..."
          ls -R dist
          echo "Deployment successful!"

Explication

needs: build: C'est la ligne clé. Elle indique à GitHub Actions que cette tâche dépend de la complétion réussie de la tâche build.
uses: actions/download-artifact@v4: Étant donné que les tâches s'exécutent sur différentes machines virtuelles, elles ne partagent pas de systèmes de fichiers. Pour obtenir le dossier dist créé dans la tâche build, nous devons télécharger l'artefact que nous avons téléversé précédemment.
name: dist-files: Doit correspondre au nom utilisé dans l'étape de téléversement.

Enregistrez le fichier (Ctrl+S ou Cmd+S).

Commit, push, et vérification de l'exécution séquentielle

Vérifions maintenant que les tâches (jobs) s'exécutent dans le bon ordre.

Assurez-vous d'être dans le répertoire du dépôt (repository) :

cd ~/project/github-actions-demo

Mettez les changements en zone de transit (stage) :

git add .

Commitez les changements :

git commit -m "Add deploy job with dependency on build"

Poussez les changements vers le dépôt distant sur GitHub :

git push

Note sur l'authentification : Lorsque vous exécutez git push, le WebIDE vous demandera automatiquement de vous authentifier. Suivez ces étapes détaillées :

Une fenêtre contextuelle apparaîtra avec le message : "The extension 'GitHub' wants to sign in using GitHub." Cliquez sur Allow.
Une nouvelle notification apparaîtra. Cliquez sur "Copy&Continue to GitHub", puis cliquez sur "Open" dans l'invite suivante.
Connectez-vous à votre compte GitHub dans la fenêtre du navigateur qui s'ouvre, et entrez le code d'autorisation qui a été copié. Après avoir confirmé l'autorisation, la page se fermera automatiquement.
Attendez quelques secondes, et vous verrez le terminal terminer avec succès l'opération de push.

Note sur la confidentialité : Le WebIDE demandera un accès complet à votre compte GitHub à des fins d'authentification. Vous n'avez pas à vous soucier des problèmes de confidentialité - la VM LabEx sera immédiatement détruite après avoir terminé le laboratoire actuel, et vos informations d'identification et d'autorisation ne seront pas conservées.

Ce processus d'authentification ne nécessite aucune configuration manuelle du nom d'utilisateur ou du Personal Access Token (Jeton d'Accès Personnel).

Vérification sur GitHub

Visitez votre dépôt sur GitHub dans un navigateur web.
Cliquez sur l'onglet Actions.
Cliquez sur la dernière exécution de workflow (workflow run).
Examinez le graphique de visualisation. Vous devriez voir deux cercles (tâches/jobs) reliés par une ligne.
- La tâche build sera à gauche.
- La tâche deploy sera à droite.
Observez la progression. Vous remarquerez que deploy reste dans un état "Pending" (En attente) ou "Waiting" jusqu'à ce que build devienne vert (Success/Succès).
Une fois que build est terminé, deploy commencera.
Cliquez sur les logs de la tâche deploy pour voir le message "Deploying project..." et la liste des fichiers de l'artefact téléchargé.

GitHub Actions job dependencies

Résumé

Dans ce laboratoire, vous avez appris à orchestrer des workflows multi-tâches (multi-job) dans GitHub Actions. Vous avez :

Créé des tâches séparées build et deploy.
Utilisé le mot-clé needs pour définir une dépendance, garantissant que deploy ne s'exécute qu'après build.
Utilisé upload-artifact et download-artifact pour transférer des données (fichiers) entre ces tâches distinctes.

Ce modèle est fondamental pour construire des pipelines CI/CD robustes où vous souhaitez construire une seule fois, puis déployer vers plusieurs environnements (staging, production) uniquement si les étapes précédentes réussissent.