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

Quel lab commencer ?

Ce lab suit naturellement le Lab 06. Si vous avez déjà manipulé workflow et rules, vous pouvez démarrer ici avec starter/lab-07.

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 — À vous de 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

👉 Vérifier votre solution (Étape 1)

1️⃣ Erreur 1 : stage invalide sur pytest

Dans starter/lab-07, le job pytest référence un stage inexistant :

pytest:
  stage: tests

Or la liste des stages contient test (sans s).

Correction attendue :

pytest:
  stage: test

Après correction, relancez glab ci lint .gitlab-ci.yml.

Étape 2 — À vous de 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.

👉 Vérifier votre solution (Étape 2)

2️⃣ Erreur 2 : dépendance needs vers un job absent

Dans starter/lab-07, pytest contient :

pytest:
  needs:
    - build-image

Le job build-image n'existe pas dans le pipeline.

Correction attendue : supprimer complètement ce bloc needs :

pytest:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - pytest -v --junitxml=report.xml

Étape 3 — À vous de 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.

👉 Vérifier votre solution (Étape 3)

3️⃣ Erreur 3 : glob invalide dans docker-build

Dans starter/lab-07, la règle changes contient un motif trop large :

docker-build:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - changes:
        - app/***
        - Dockerfile
        - requirements.txt

Correction attendue :

docker-build:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - changes:
        - app/**/*
        - Dockerfile
        - requirements.txt

Le motif app/**/* correspond au comportement de solution/lab-07.

Étape 4 — À vous d'appliquer une 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érifier votre solution (Étape 4)

1️⃣ Routine complète avant push

# 1. Valider la syntaxe CI
glab ci lint .gitlab-ci.yml

# 2. Linter le code Python
ruff check app/ tests/

# 3. Tests rapides en local
pytest -q

# 4. Pousser seulement si tout est vert
git add .gitlab-ci.yml
git commit -m "ci: fix lint issues before push"
git push origin starter/lab-07

Cette routine peut être automatisée via un hook git pre-push :

.git/hooks/pre-push

#!/bin/bash
glab ci lint .gitlab-ci.yml || exit 1

Rendez le hook exécutable : chmod +x .git/hooks/pre-push

2️⃣ Résultat attendu sur ce lab

Une fois les 3 corrections faites (stage: test, suppression de needs: build-image, app/**/*), glab ci lint devient valide et le pipeline repart sans erreur de configuration.

Le fichier complet

📄 Voir le fichier .gitlab-ci.yml complet

stages:
  - lint
  - test
  - build
  - deploy

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"

ruff-lint:
  stage: lint
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
    policy: pull
  before_script:
    - pip install ruff
  script:
    - ruff check app/ tests/
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

pytest:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - pytest -v --junitxml=report.xml
  artifacts:
    when: always
    paths:
      - report.xml
    reports:
      junit: report.xml
    expire_in: 7 days
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

docker-build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - changes:
        - app/**/*
        - Dockerfile
        - requirements.txt

deploy-staging:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to staging..."
    - ./scripts/deploy-demo.sh staging
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to production..."
    - ./scripts/deploy-demo.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Vérification

• pytest utilise stage: test (et non tests)
• Le bloc needs: - build-image est supprimé du job pytest
• La règle changes de docker-build contient app/**/*
• glab ci lint retourne une configuration valide

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 →