Exercice 03 : Accélérer le pipeline avec le cache

🎯 Objectifs

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

✅ Configurer cache: 'npm' dans actions/setup-node@v4
✅ Distinguer un cache hit d'un cache miss dans les logs
✅ Comprendre comment la clé est dérivée du hash de package-lock.json
✅ Observer la réduction de durée entre le premier et le second run

Durée estimée : 20 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

À chaque run, npm ci télécharge toutes les dépendances depuis Internet. Sur un projet avec 200 packages, cela prend facilement 30 à 60 secondes. Le cache permet à GitHub Actions de sauvegarder le dossier node_modules (ou le cache npm local) et de le restaurer au run suivant si package-lock.json n'a pas changé.

La clé de cache est un hash du fichier de lock. Si le fichier change (nouvelle dépendance ajoutée), la clé change et le cache est régénéré.

📋 Énoncé

Vous allez créer un workflow qui installe des dépendances npm avec le cache activé, observer les logs sur deux runs successifs, et mesurer le gain de temps.

Résultat attendu :

Premier run : "Cache not found" → npm ci lent (~15-30s)
Second run : "Cache restored" → npm ci rapide (~1-3s)

🧭 Déroulement

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

Dans votre repository, créez un package.json minimal avec Jest comme dépendance de développement, puis générez un package-lock.json avec npm install.

Indice :
`json
{
"name": "mon-projet",
"version": "1.0.0",
"devDependencies": {
"jest": "^29.0.0"
}
}
`
La commande npm install crée le package-lock.json. Committez les deux fichiers.

Vérification : package.json et package-lock.json sont présents dans le repository.

Tâche 2 : Activer le cache dans setup-node

Créez .github/workflows/cache-demo.yml. Dans le step actions/setup-node@v4, ajoutez l'option cache: 'npm'.

Indice :
`yaml
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
`
L'option cache: 'npm' dit à l'action de gérer le cache du répertoire ~/.npm en se basant sur le hash de package-lock.json.

Vérification : Le workflow contient cache: 'npm' dans le step setup-node.

Tâche 3 : Observer le premier run (cache miss)

Poussez le workflow et observez les logs du job. Dans les logs du step setup-node, cherchez le message indiquant que le cache n'a pas été trouvé.

Indice : Dans les logs de setup-node, vous verrez soit Cache not found for input keys (cache miss) soit Cache restored from key (cache hit). Notez également la durée du step npm ci.

Vérification : Les logs affichent "Cache not found" et npm ci prend plus de 10 secondes.

Tâche 4 : Observer le second run (cache hit)

Faites un second push sans modifier package-lock.json (par exemple, modifiez le README). Comparez la durée du step npm ci avec le premier run.

Indice : La clé de cache est construite automatiquement par setup-node à partir du hash de package-lock.json. Si ce fichier n'a pas changé entre deux runs, la même clé est utilisée et le cache est restauré.

Vérification : Les logs du second run affichent "Cache restored from key: ..." et npm ci s'exécute en moins de 5 secondes.

Tâche 5 : Invalider le cache manuellement

Ajoutez une nouvelle dépendance dans package.json (ex: "axios": "^1.0.0"), relancez npm install, et poussez. Observez que le cache est invalidé.

Indice : Ajouter une dépendance modifie package-lock.json, ce qui change son hash, ce qui génère une nouvelle clé de cache. GitHub Actions crée un nouveau cache pour cette nouvelle clé.

Vérification : Les logs affichent à nouveau "Cache not found" (nouvelle clé), puis "Cache saved successfully" à la fin du job.

🗂️ Mini-Projet : Workflow avec cache et rapport de durée

Créez un workflow qui mesure et affiche le temps d'installation des dépendances :

yaml

# Checkpoints à valider :
# [ ] package.json et package-lock.json sont dans le repository
# [ ] cache: 'npm' est configuré dans actions/setup-node@v4
# [ ] Premier run : "Cache not found" dans les logs setup-node
# [ ] Second run (sans changer package-lock.json) : "Cache restored"
# [ ] Durée du step npm ci inférieure à 5s au second run
# [ ] Bonus : utilisez time npm ci pour afficher la durée précise

Exercice 03 : Accélérer le pipeline avec le cache

🎯 Objectifs

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

✅ Configurer cache: 'npm' dans actions/setup-node@v4
✅ Distinguer un cache hit d'un cache miss dans les logs
✅ Comprendre comment la clé est dérivée du hash de package-lock.json
✅ Observer la réduction de durée entre le premier et le second run

Durée estimée : 20 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

La clé de cache est un hash du fichier de lock. Si le fichier change (nouvelle dépendance ajoutée), la clé change et le cache est régénéré.

📋 Énoncé

Vous allez créer un workflow qui installe des dépendances npm avec le cache activé, observer les logs sur deux runs successifs, et mesurer le gain de temps.

Résultat attendu :

Premier run : "Cache not found" → npm ci lent (~15-30s)
Second run : "Cache restored" → npm ci rapide (~1-3s)

🧭 Déroulement

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

Dans votre repository, créez un package.json minimal avec Jest comme dépendance de développement, puis générez un package-lock.json avec npm install.

Indice :
`json
{
"name": "mon-projet",
"version": "1.0.0",
"devDependencies": {
"jest": "^29.0.0"
}
}
`
La commande npm install crée le package-lock.json. Committez les deux fichiers.

Vérification : package.json et package-lock.json sont présents dans le repository.

Tâche 2 : Activer le cache dans setup-node

Créez .github/workflows/cache-demo.yml. Dans le step actions/setup-node@v4, ajoutez l'option cache: 'npm'.

Indice :
`yaml
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
`
L'option cache: 'npm' dit à l'action de gérer le cache du répertoire ~/.npm en se basant sur le hash de package-lock.json.

Vérification : Le workflow contient cache: 'npm' dans le step setup-node.

Tâche 3 : Observer le premier run (cache miss)

Poussez le workflow et observez les logs du job. Dans les logs du step setup-node, cherchez le message indiquant que le cache n'a pas été trouvé.

Indice : Dans les logs de setup-node, vous verrez soit Cache not found for input keys (cache miss) soit Cache restored from key (cache hit). Notez également la durée du step npm ci.

Vérification : Les logs affichent "Cache not found" et npm ci prend plus de 10 secondes.

Tâche 4 : Observer le second run (cache hit)

Faites un second push sans modifier package-lock.json (par exemple, modifiez le README). Comparez la durée du step npm ci avec le premier run.

Indice : La clé de cache est construite automatiquement par setup-node à partir du hash de package-lock.json. Si ce fichier n'a pas changé entre deux runs, la même clé est utilisée et le cache est restauré.

Vérification : Les logs du second run affichent "Cache restored from key: ..." et npm ci s'exécute en moins de 5 secondes.

Tâche 5 : Invalider le cache manuellement

Ajoutez une nouvelle dépendance dans package.json (ex: "axios": "^1.0.0"), relancez npm install, et poussez. Observez que le cache est invalidé.

Indice : Ajouter une dépendance modifie package-lock.json, ce qui change son hash, ce qui génère une nouvelle clé de cache. GitHub Actions crée un nouveau cache pour cette nouvelle clé.

Vérification : Les logs affichent à nouveau "Cache not found" (nouvelle clé), puis "Cache saved successfully" à la fin du job.

🗂️ Mini-Projet : Workflow avec cache et rapport de durée

Créez un workflow qui mesure et affiche le temps d'installation des dépendances :

yaml

# Checkpoints à valider :
# [ ] package.json et package-lock.json sont dans le repository
# [ ] cache: 'npm' est configuré dans actions/setup-node@v4
# [ ] Premier run : "Cache not found" dans les logs setup-node
# [ ] Second run (sans changer package-lock.json) : "Cache restored"
# [ ] Durée du step npm ci inférieure à 5s au second run
# [ ] Bonus : utilisez time npm ci pour afficher la durée précise