Lab 07 — Valider un pipeline

Vous avez déjà construit un pipeline solide, avec des conditions d’exécution et des jobs de déploiement. Le problème maintenant, c’est la vitesse de feedback. Une faute d’indentation YAML ou un stage mal nommé vous oblige à pousser, attendre le pipeline, puis corriger. Ce lab vous apprend à valider votre pipeline avant de pousser pour gagner du temps et éviter les erreurs triviales.

Objectif rapide

À la fin du lab, vous saurez détecter les erreurs de configuration avec glab ci lint et la page CI Lint de GitLab avant de déclencher un pipeline réel.

Série de labs

Cette page fait partie d’une série de labs progressifs sur Pipeline Craft. Pour comprendre le projet fil rouge, le workflow fork → starter → solution et la progression complète, commencez par Labs Pipeline Craft.

Ce que vous allez apprendre

• Valider un .gitlab-ci.yml localement avec glab ci lint
• Distinguer une erreur YAML d’une erreur logique CI
• Utiliser l’outil CI Lint dans l’interface GitLab
• Réduire les cycles push-attente-correction

Dans quel contexte ?

Quand une équipe a un pipeline simple, les erreurs sont peu fréquentes. Mais dès qu’on ajoute rules, workflow, artifacts, needs, les fautes de configuration deviennent courantes. Un pipeline peut être YAML valide et CI invalide. C’est ce qui provoque les erreurs frustrantes détectées trop tard.

Dans la pratique, valider avant push permet d’éviter :

• des pipelines cassés pour une simple typo
• des jobs bloqués à cause d’un stage inexistant
• des allers-retours inutiles pendant les revues de Merge Request

Prérequis

• Lab 06 — Contrôler l’exécution terminé
• Avoir glab installé et authentifié
• Avoir lu Valider un .gitlab-ci.yml (conseillé)

Point de départ

1. Placez-vous sur la branche de travail

   cd pipeline-craft
   git checkout starter/lab-07

2. Ouvrez .gitlab-ci.yml et lisez-le une première fois

   La branche de départ contient volontairement des erreurs classiques pour simuler un vrai contexte d’équipe.

Le problème

Dans cette branche, le pipeline peut présenter trois types d’erreurs :

• une erreur de structure YAML (indentation, clé mal positionnée)
• un stage référencé par un job mais absent de stages:
• une dépendance needs qui pointe vers un job inexistant

L’objectif n’est pas de deviner. L’objectif est de valider systématiquement avec les bons outils.

L’exercice

Étape 1 — Lancer un lint local

1. Exécutez la validation CLI

   glab ci lint .gitlab-ci.yml

2. Lisez le message de sortie

   Si le lint échoue, GitLab indique généralement la clé fautive et la zone concernée. Corrigez une erreur à la fois, puis relancez la commande.

3. Répétez jusqu’à obtenir un état valide

   Valid configuration

Étape 2 — Vérifier dans l’interface GitLab

1. Ouvrez votre projet GitLab, puis allez dans Build > Pipeline editor
2. Collez le contenu du .gitlab-ci.yml
3. Utilisez le bouton de validation (CI Lint) L’interface complète bien la CLI. Elle permet parfois de mieux visualiser la structure du pipeline et les jobs impactés.

Étape 3 — Vérifier la logique CI

1. Contrôlez la cohérence des stages

   Vérifiez que chaque job pointe vers un stage existant.

2. Contrôlez les références needs

   Si un job dépend d’un autre job supprimé ou renommé, le pipeline est invalide même si le YAML est correct.

3. Contrôlez les règles

   Une règle trop restrictive peut produire un pipeline vide ou des jobs tous skip.

Étape 4 — Routine de validation avant push

1. Exécutez vos validations locales

   glab ci lint .gitlab-ci.yml
   ruff check app/ tests/
   pytest -q

2. Commitez et poussez seulement après validation

   git add .gitlab-ci.yml
   git commit -m "ci: fix lint issues before push"
   git push origin starter/lab-07

Vérification

• glab ci lint retourne une configuration valide
• Le pipeline se lance sans erreur de parsing
• Aucun job ne référence un stage absent
• Le premier push après correction passe sans erreur de configuration

Pièges fréquents

Un lint vert ne signifie pas que tout est parfait. Par exemple, un fichier peut être syntaxiquement valide mais exécuter zéro job à cause de règles trop restrictives. C’est pour cela qu’il faut compléter le lint par une lecture de la logique globale (workflow, rules, needs).

Autre piège : corriger plusieurs zones en même temps. Sur un pipeline long, corriger une erreur à la fois réduit le risque d’introduire une nouvelle faute pendant le correctif.

À retenir

• glab ci lint est votre premier filet de sécurité
• YAML valide ne veut pas toujours dire pipeline correct
• Valider avant push économise du temps et des minutes CI
• Une routine de validation simple évite la majorité des erreurs triviales

Prochaines étapes

Lab 08 — Déclencher un pipeline Exécuter un pipeline autrement qu'avec un push

Guide : validation pipeline Référence complète sur les outils de lint GitLab

Retour au Lab 06 Revoir workflow et rules

×

📖 Voir la documentation →