Lab 10 — Rapports qualité

Un pipeline vert rassure, mais ne dit pas tout. Sans rapports qualité visibles dans la MR, les reviewers ne savent pas quels tests échouent, ni si la couverture monte ou baisse. Ce lab vous apprend à rendre les résultats lisibles directement dans GitLab pour améliorer la décision de merge.

Objectif rapide

Vous allez publier un rapport JUnit et afficher un pourcentage de couverture directement dans GitLab.

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

• Générer un rapport JUnit depuis pytest
• Publier ce rapport comme artifact reconnu par GitLab
• Extraire une couverture avec coverage:
• Lire ces informations dans les widgets de Merge Request

Dans quel contexte ?

Dans un flux d’équipe, la MR est le point de vérité pour décider un merge. Si les infos qualité sont cachées dans des logs longs, elles sont peu consultées. En affichant les résultats au bon endroit, vous rendez la qualité visible et actionnable.

Ce lab répond à des besoins réels :

• repérer immédiatement un test cassé dans une MR
• suivre l’évolution de la couverture
• éviter les merges “à l’aveugle”

Prérequis

• Lab 09 — Publier dans le registry terminé
• Avoir lu Rapports qualité

Point de départ

1. Basculez sur la branche du lab

   cd pipeline-craft
   git checkout starter/lab-10

2. Ouvrez le job pytest dans .gitlab-ci.yml

   Vous allez y ajouter la production de rapport et l’extraction de couverture.

Le problème

Sans configuration explicite, GitLab ne sait pas interpréter vos résultats de test. Vous devez lui fournir :

• un fichier JUnit via artifacts.reports.junit
• une expression coverage: pour extraire le pourcentage

L’exercice

Étape 1 — Générer le rapport JUnit

1. Modifiez la commande pytest

   script:
     - pytest -v --junitxml=report.xml --cov=app --cov-report=term-missing

2. Ajoutez l’artifact JUnit

   artifacts:
     when: always
     paths:
       - report.xml
     reports:
       junit: report.xml
     expire_in: 7 days

   Le when: always est important pour conserver le rapport même en cas d’échec.

Étape 2 — Extraire la couverture

1. Ajoutez la regex de couverture sur le job pytest

   coverage: '/TOTAL\s+\d+\s+\d+\s+(\d+%)/'

2. Vérifiez localement la sortie de pytest

   La regex doit correspondre à la ligne TOTAL ... 87% du rapport terminal.

3. Ajustez la regex si besoin

   Une regex trop stricte est une cause classique de couverture “non détectée”.

Étape 3 — Vérifier dans la MR

1. Poussez vos modifications

   git add .gitlab-ci.yml
   git commit -m "ci: publish junit and coverage"
   git push origin starter/lab-10

2. Ouvrez une Merge Request

3. Vérifiez l’onglet tests et la couverture affichée

   L’objectif est de lire la qualité sans ouvrir les logs complets.

Vérification

• report.xml est généré et publié
• GitLab affiche les tests dans la MR
• Le pourcentage de couverture est extrait
• Les reviewers peuvent lire les résultats sans parcourir les logs

Pièges fréquents

La couverture peut ne pas apparaître si la regex ne matche pas la sortie réelle. Vérifiez toujours la ligne exacte produite par pytest-cov.

Le rapport JUnit peut être vide si le chemin est incorrect ou si la commande pytest échoue avant génération. Dans ce cas, when: always aide au diagnostic car l’artifact est tout de même uploadé.

À retenir

• Les rapports qualité doivent être visibles dans la MR, pas cachés dans les logs
• JUnit + coverage améliore la revue et la confiance de merge
• Une bonne regex coverage est essentielle
• Les artifacts rendent le diagnostic reproductible

Prochaines étapes

Lab 11 — Débugger un job bloqué Diagnostiquer pending et skipped

Guide : rapports qualité Approfondir JUnit, coverage et widgets MR

Retour au Lab 09 Publier dans le registry

×

📖 Voir la documentation →