Exercice 04 : Publier des artefacts dans GitLab CI

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Configurer artifacts: paths: pour conserver des fichiers entre jobs
✅ Utiliser artifacts: when: always pour publier même en cas d'échec
✅ Définir expire_in: pour nettoyer automatiquement les artefacts
✅ Configurer artifacts: reports: junit: pour afficher les résultats de tests dans une MR

Durée estimée : 20 minutes

Difficulté : ⭐⭐☆☆☆ (Débutant)

Prérequis :

Exercices 01 à 03 complétés
Compte GitLab.com avec un projet

📖 Contexte

Les artefacts sont des fichiers produits par un job et conservés par GitLab. Ils peuvent être téléchargés depuis l'interface, transmis aux jobs suivants, ou utilisés pour alimenter les widgets de GitLab (rapports de tests, couverture de code, etc.). Sans artefacts, chaque job repart d'un environnement vide.

📋 Énoncé

Créez un pipeline avec un job de build qui produit un binaire, un job de test qui génère un rapport JUnit, et configurez les artefacts pour que les fichiers soient conservés et visibles dans GitLab.

🧭 Déroulement de l'exercice

Tâche 1 : Produire et conserver un artefact de build

Créez un job build qui génère un dossier dist/ avec un fichier simulé app.tar.gz. Configurez artifacts: paths: pour que GitLab conserve ce dossier.

Indice :
`yaml
artifacts:
paths:
- dist/
expire_in: 1 week
`
expire_in accepte des formats comme 30 mins, 1 hour, 7 days, 1 week, never.

Vérification : Après le pipeline, un bouton "Download artifacts" apparaît sur le job build dans l'interface GitLab.

Tâche 2 : Utiliser l'artefact dans un job suivant

Créez un job package dans le stage suivant qui utilise le dossier dist/ produit par build. Il doit lister le contenu de dist/ avec ls -la dist/.

Indice : Par défaut, GitLab télécharge automatiquement les artefacts des jobs précédents dans le même pipeline. Le job package trouve donc dist/ sans configuration supplémentaire.

Vérification : Le job package liste correctement le fichier app.tar.gz dans ses logs.

Tâche 3 : Générer un rapport de tests JUnit

Créez un job tests qui génère un fichier junit-report.xml simulé avec un test réussi. Configurez artifacts: reports: junit: pour que GitLab l'analyse.

Indice : Format minimal d'un rapport JUnit valide :
`xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
<testsuite name="unit" tests="2" failures="0">
<testcase name="test login" classname="auth"/>
<testcase name="test register" classname="auth"/>
</testsuite>
</testsuites>
`
Créez ce fichier avec cat > junit-report.xml << 'EOF'.

Vérification : Dans le pipeline GitLab, le job tests affiche un badge "2 tests, 0 failures".

Tâche 4 : Conserver les artefacts même en cas d'échec

Modifiez le job tests pour qu'il publie toujours son rapport JUnit, même si les tests échouent, en utilisant when: always.

Indice : Par défaut, when: on_success signifie que les artefacts ne sont conservés qu'en cas de succès du job. when: always est indispensable pour les rapports de tests car on veut lire le rapport même quand les tests échouent.

Vérification : En forçant exit 1 dans le script (puis en le retirant), le rapport est quand même disponible en téléchargement.

Tâche 5 : Configurer différentes durées d'expiration

Donnez des durées différentes aux artefacts : dist/ expire dans 1 week, le rapport JUnit dans 30 days. Vérifiez dans l'interface GitLab que les dates d'expiration sont correctes.

Indice : Chaque job peut avoir sa propre section artifacts: avec sa propre expire_in. L'artefact de build (lourd) peut expirer vite, le rapport de tests peut être conservé plus longtemps pour l'historique.

Vérification : Les deux jobs affichent des dates d'expiration différentes dans "Browse artifacts".

🗂️ Mini-Projet : Pipeline avec artefacts

Checkpoints de validation :

dist/app.tar.gz est téléchargeable depuis le job build
Le job package trouve dist/ sans configuration additionnelle
Le rapport JUnit est affiché dans le pipeline (badge tests)
when: always conserve le rapport même si les tests échouent
Les deux artefacts ont des durées d'expiration différentes

Exercice 04 : Publier des artefacts dans GitLab CI

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Configurer artifacts: paths: pour conserver des fichiers entre jobs
✅ Utiliser artifacts: when: always pour publier même en cas d'échec
✅ Définir expire_in: pour nettoyer automatiquement les artefacts
✅ Configurer artifacts: reports: junit: pour afficher les résultats de tests dans une MR

Durée estimée : 20 minutes

Difficulté : ⭐⭐☆☆☆ (Débutant)

Prérequis :

Exercices 01 à 03 complétés
Compte GitLab.com avec un projet

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Produire et conserver un artefact de build

Créez un job build qui génère un dossier dist/ avec un fichier simulé app.tar.gz. Configurez artifacts: paths: pour que GitLab conserve ce dossier.

Indice :
`yaml
artifacts:
paths:
- dist/
expire_in: 1 week
`
expire_in accepte des formats comme 30 mins, 1 hour, 7 days, 1 week, never.

Vérification : Après le pipeline, un bouton "Download artifacts" apparaît sur le job build dans l'interface GitLab.

Tâche 2 : Utiliser l'artefact dans un job suivant

Créez un job package dans le stage suivant qui utilise le dossier dist/ produit par build. Il doit lister le contenu de dist/ avec ls -la dist/.

Indice : Par défaut, GitLab télécharge automatiquement les artefacts des jobs précédents dans le même pipeline. Le job package trouve donc dist/ sans configuration supplémentaire.

Vérification : Le job package liste correctement le fichier app.tar.gz dans ses logs.

Tâche 3 : Générer un rapport de tests JUnit

Créez un job tests qui génère un fichier junit-report.xml simulé avec un test réussi. Configurez artifacts: reports: junit: pour que GitLab l'analyse.

Indice : Format minimal d'un rapport JUnit valide :
`xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
<testsuite name="unit" tests="2" failures="0">
<testcase name="test login" classname="auth"/>
<testcase name="test register" classname="auth"/>
</testsuite>
</testsuites>
`
Créez ce fichier avec cat > junit-report.xml << 'EOF'.

Vérification : Dans le pipeline GitLab, le job tests affiche un badge "2 tests, 0 failures".

Tâche 4 : Conserver les artefacts même en cas d'échec

Modifiez le job tests pour qu'il publie toujours son rapport JUnit, même si les tests échouent, en utilisant when: always.

Indice : Par défaut, when: on_success signifie que les artefacts ne sont conservés qu'en cas de succès du job. when: always est indispensable pour les rapports de tests car on veut lire le rapport même quand les tests échouent.

Vérification : En forçant exit 1 dans le script (puis en le retirant), le rapport est quand même disponible en téléchargement.

Tâche 5 : Configurer différentes durées d'expiration

Donnez des durées différentes aux artefacts : dist/ expire dans 1 week, le rapport JUnit dans 30 days. Vérifiez dans l'interface GitLab que les dates d'expiration sont correctes.

Indice : Chaque job peut avoir sa propre section artifacts: avec sa propre expire_in. L'artefact de build (lourd) peut expirer vite, le rapport de tests peut être conservé plus longtemps pour l'historique.

Vérification : Les deux jobs affichent des dates d'expiration différentes dans "Browse artifacts".

🗂️ Mini-Projet : Pipeline avec artefacts

Checkpoints de validation :

dist/app.tar.gz est téléchargeable depuis le job build
Le job package trouve dist/ sans configuration additionnelle
Le rapport JUnit est affiché dans le pipeline (badge tests)
when: always conserve le rapport même si les tests échouent
Les deux artefacts ont des durées d'expiration différentes