Exercice 02 : Optimiser le pipeline avec le cache GitLab CI

🎯 Objectifs

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

✅ Configurer cache: key: files: avec le hash de package-lock.json
✅ Choisir la politique pull-push (lecture + écriture) ou pull (lecture seule)
✅ Scoper le cache par branche avec $CI_COMMIT_REF_SLUG
✅ Mesurer la réduction du temps d'installation entre le premier et le second run

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Module GitLab CI Intermédiaire - Exercice 01 complété
Connaissances Node.js basiques (npm ci)

📖 Contexte

Sans cache, chaque job GitLab CI repart d'un environnement vide. L'installation de node_modules/ avec npm ci peut prendre 30 à 120 secondes selon les dépendances. Le cache GitLab permet de conserver ces dossiers entre les pipelines et de les restaurer en quelques secondes.

📋 Énoncé

Créez un pipeline Node.js avec un cache intelligent sur node_modules/. Le cache se régénère automatiquement quand package-lock.json change. Les jobs de test n'écrivent pas dans le cache (politique pull).

🧭 Déroulement de l'exercice

Tâche 1 : Créer un projet Node.js minimaliste

Dans votre dépôt, créez un package.json avec une dépendance de dev (ex: jest). Générez le package-lock.json avec npm install en local. Committez les deux fichiers.

Indice :
`json
{
"name": "cache-demo",
"scripts": { "test": "jest" },
"devDependencies": { "jest": "^29.0.0" }
}
`
Le package-lock.json est le fichier de référence pour le cache : son hash change uniquement quand les dépendances changent.

Vérification : package.json et package-lock.json sont dans le dépôt.

Tâche 2 : Configurer le cache global avec key files

Dans .gitlab-ci.yml, configurez un cache global dont la clé est le hash de package-lock.json et qui cible le dossier node_modules/.

Indice :
`yaml
cache:
key:
files:
- package-lock.json
paths:
- node_modules/
`
key: files: calcule automatiquement un hash MD5 des fichiers listés. Si package-lock.json ne change pas, la même clé est réutilisée et node_modules/ est restauré depuis le cache.

Vérification : Au second push sans modifier package-lock.json, les logs affichent "Restoring cache" dans le job.

Tâche 3 : Configurer la politique pull-push pour l'installation

Créez un job install (stage build) qui exécute npm ci. Configurez sa politique de cache sur pull-push : il restaure le cache ET le met à jour après l'installation.

Indice :
`yaml
install:
cache:
policy: pull-push
`
pull-push est la politique par défaut. Elle restaure le cache en début de job et le sauvegarde en fin de job. Un seul job par pipeline doit écrire dans le cache.

Vérification : Après le premier run, les logs montrent "Saving cache" à la fin du job install.

Tâche 4 : Configurer la politique pull pour les tests

Créez un job test (stage test) qui exécute npm test. Configurez sa politique sur pull : il ne fait que restaurer le cache sans l'écrire.

Indice :
`yaml
test:
cache:
policy: pull
`
pull accélère la fin du job car il ne sauvegarde pas le cache. Utilisez pull pour tous les jobs qui ne modifient pas node_modules/.

Vérification : Les logs du job test n'affichent pas "Saving cache" - uniquement "Restoring cache".

Tâche 5 : Scoper le cache par branche

Modifiez la clé de cache pour qu'elle inclue à la fois le hash de package-lock.json ET la branche ($CI_COMMIT_REF_SLUG). Cela évite que des branches différentes partagent le même cache.

Indice :
`yaml
cache:
key: "$CI_COMMIT_REF_SLUG-${CI_FILES_HASH}"
`
Ou plus élégamment avec key: files: et prefix: :
`yaml
cache:
key:
files:
- package-lock.json
prefix: $CI_COMMIT_REF_SLUG
paths:
- node_modules/
`

Vérification : Sur deux branches différentes, deux entrées de cache distinctes sont créées.

🗂️ Mini-Projet : Pipeline avec cache optimisé

Checkpoints de validation :

Premier run : npm ci installe depuis le réseau (lent)
Second run sans changer package-lock.json : cache restauré (rapide)
Modifier package-lock.json invalide le cache (nouveau hash)
Le job test utilise policy: pull (pas de "Saving cache" dans ses logs)
Deux branches ont des entrées de cache séparées

Exercice 02 : Optimiser le pipeline avec le cache GitLab CI

🎯 Objectifs

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

✅ Configurer cache: key: files: avec le hash de package-lock.json
✅ Choisir la politique pull-push (lecture + écriture) ou pull (lecture seule)
✅ Scoper le cache par branche avec $CI_COMMIT_REF_SLUG
✅ Mesurer la réduction du temps d'installation entre le premier et le second run

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Module GitLab CI Intermédiaire - Exercice 01 complété
Connaissances Node.js basiques (npm ci)

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Créer un projet Node.js minimaliste

Dans votre dépôt, créez un package.json avec une dépendance de dev (ex: jest). Générez le package-lock.json avec npm install en local. Committez les deux fichiers.

Indice :
`json
{
"name": "cache-demo",
"scripts": { "test": "jest" },
"devDependencies": { "jest": "^29.0.0" }
}
`
Le package-lock.json est le fichier de référence pour le cache : son hash change uniquement quand les dépendances changent.

Vérification : package.json et package-lock.json sont dans le dépôt.

Tâche 2 : Configurer le cache global avec key files

Dans .gitlab-ci.yml, configurez un cache global dont la clé est le hash de package-lock.json et qui cible le dossier node_modules/.

Indice :
`yaml
cache:
key:
files:
- package-lock.json
paths:
- node_modules/
`
key: files: calcule automatiquement un hash MD5 des fichiers listés. Si package-lock.json ne change pas, la même clé est réutilisée et node_modules/ est restauré depuis le cache.

Vérification : Au second push sans modifier package-lock.json, les logs affichent "Restoring cache" dans le job.

Tâche 3 : Configurer la politique pull-push pour l'installation

Créez un job install (stage build) qui exécute npm ci. Configurez sa politique de cache sur pull-push : il restaure le cache ET le met à jour après l'installation.

Indice :
`yaml
install:
cache:
policy: pull-push
`
pull-push est la politique par défaut. Elle restaure le cache en début de job et le sauvegarde en fin de job. Un seul job par pipeline doit écrire dans le cache.

Vérification : Après le premier run, les logs montrent "Saving cache" à la fin du job install.

Tâche 4 : Configurer la politique pull pour les tests

Créez un job test (stage test) qui exécute npm test. Configurez sa politique sur pull : il ne fait que restaurer le cache sans l'écrire.

Indice :
`yaml
test:
cache:
policy: pull
`
pull accélère la fin du job car il ne sauvegarde pas le cache. Utilisez pull pour tous les jobs qui ne modifient pas node_modules/.

Vérification : Les logs du job test n'affichent pas "Saving cache" - uniquement "Restoring cache".

Tâche 5 : Scoper le cache par branche

Modifiez la clé de cache pour qu'elle inclue à la fois le hash de package-lock.json ET la branche ($CI_COMMIT_REF_SLUG). Cela évite que des branches différentes partagent le même cache.

Indice :
`yaml
cache:
key: "$CI_COMMIT_REF_SLUG-${CI_FILES_HASH}"
`
Ou plus élégamment avec key: files: et prefix: :
`yaml
cache:
key:
files:
- package-lock.json
prefix: $CI_COMMIT_REF_SLUG
paths:
- node_modules/
`

Vérification : Sur deux branches différentes, deux entrées de cache distinctes sont créées.

🗂️ Mini-Projet : Pipeline avec cache optimisé

Checkpoints de validation :

Premier run : npm ci installe depuis le réseau (lent)
Second run sans changer package-lock.json : cache restauré (rapide)
Modifier package-lock.json invalide le cache (nouveau hash)
Le job test utilise policy: pull (pas de "Saving cache" dans ses logs)
Deux branches ont des entrées de cache séparées