Gitlab - 4.4.2 Écriture du pipeline gitlab

Maintenant que vous connaissez les commandes et le flux nécessaires pour exécuter un pipeline GitLab, l'idéal est de créer votre propre fichier .gitlab-ci.yml en même temps que moi. La même approche s'applique : créer les fichiers localement, les pousser sur votre branche, exécuter le pipeline, puis fusionner avec master. Comme chaque pipeline commence par la définition d'un job, nous aurons ici besoin de deux jobs : un job Build qui installe les dépendances, et un job Deploy qui exécute l'application.

Définition des deux jobs Build et Deploy

Commençons par le job de build. Comme nous l'avons vu lors de la session précédente, npm doit être installé avant d'être utilisé. Dans le bloc script, on écrit donc la commande d'installation de Node, puis celle de npm (Node Package Manager). Une fois npm en place, on installe les dépendances déclarées dans package.json à la racine via la simple commande npm install.

build_app:
  script:
    - apt install nodejs -y
    - apt install npm -y
    - npm install

deploy_app:
  script:
    - apt install nodejs -y
    - node index.js

Une fois le build terminé, on définit un second job qui exécute le fichier index.js. Attention, l'environnement GitLab par défaut n'a pas Node installé : il faut donc l'installer explicitement avant d'utiliser node index.js. Vous pourriez vous demander pourquoi ne pas regrouper l'installation de Node dans le job de build : votre question est légitime, et vous aurez bientôt la réponse en abordant les artefacts et les stages.

  • Job build_app : install Node, install npm, npm install
  • Job deploy_app : install Node, node index.js
  • L'ordre d'écriture des jobs n'impose pas l'ordre d'exécution
  • Sans stages, GitLab exécute les jobs en parallèle
  • Exclure node_modules/ du push (généré par le pipeline)

Les deux jobs sont prêts. On commit le fichier et on l'envoie sur la branche dev (en excluant le dossier node_modules/, qui sera généré par le pipeline). Mais un problème se pose : dans quel ordre GitLab va-t-il exécuter ces jobs ? L'ordre dans lequel ils sont définis dans le fichier YAML n'a aucune importance. Par défaut, GitLab les exécute en parallèle. Résultat prévisible : le pipeline échoue car le job de déploiement tente de démarrer l'application avant que le build n'ait installé les dépendances.

Pour éviter ce comportement par défaut, nous devons indiquer explicitement à GitLab dans quel ordre exécuter les jobs. C'est exactement le rôle des stages (étapes), que nous explorerons en détail dans la prochaine leçon.

En résumé

Cette leçon explique comment écrire un pipeline GitLab (.gitlab-ci) en créant deux jobs : un job de build pour installer les dépendances NPM, et un job de déploiement pour exécuter l'application. Le transcript aborde le problème critique de l'ordre d'exécution : par défaut, GitLab exécute les jobs en parallèle, ce qui peut causer des erreurs si un job dépend d'un autre. Pour résoudre cela, il faut définir des stages (étapes) dans le pipeline.

Points clés

  • Un pipeline GitLab commence par la définition de jobs : au minimum, un job de build et un job de déploiement
  • Le job de build doit installer Node.js et les dépendances NPM (via 'npm install') avant que l'application puisse être exécutée
  • Par défaut, GitLab exécute les jobs en parallèle, ce qui crée une interdépendance problématique : le déploiement s'exécute avant la fin du build
  • L'ordre de définition des jobs dans le fichier .gitlab-ci n'affecte pas leur ordre d'exécution
  • Pour contrôler l'ordre d'exécution, il faut utiliser les 'stages' (étapes) dans le pipeline
  • Le workflow recommandé : créer les fichiers localement, pousser sur une branche, tester le pipeline, puis fusionner avec main

Questions fréquentes

Pourquoi doit-on installer Node.js explicitement dans chaque job qui l'utilise ?

Parce que l'environnement GitLab Runner n'a pas Node.js pré-installé par défaut. Chaque job exécutant du code Node.js doit d'abord installer Node.js dans la section 'script' du job.

Comment contrôler l'ordre d'exécution des jobs dans un pipeline GitLab ?

En définissant des 'stages' (étapes) dans le fichier .gitlab-ci. Les stages contrôlent l'ordre d'exécution séquentiel des jobs. Cela sera détaillé dans la leçon suivante.

Pourquoi ne faut-il pas pousser le dossier node_modules sur la branche ?

Parce que node_modules est volumineux et sera régénéré de toute façon lors de la build du pipeline via la commande 'npm install'. Seuls les fichiers source et package.json doivent être versionés.