Mise en cache des builds en intégration continue : clés, repli de restauration et empoisonnement du cache

Objectif

Réduire la durée du pipeline en réutilisant les téléchargements de dépendances et les couches d'image, sans laisser le cache modifier les résultats de la build ni devenir une voie d'injection de code.

Prérequis

Des fichiers de verrouillage pour chaque gestionnaire de paquets du dépôt ; un Dockerfile ordonné de sorte que l'installation des dépendances précède la copie des sources ; un système d'intégration continue doté d'une action de cache ou d'un registre accessible depuis le constructeur (builder).

Étapes

1. Indexer les caches de dépendances sur le système d'exploitation plus un hachage du fichier de verrouillage (${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}), et lister les restore-keys du plus spécifique au moins spécifique, afin qu'un changement du fichier de verrouillage restaure le cache ancien le plus proche plutôt que de repartir à froid. La documentation GitHub citée décrit d'abord la correspondance exacte, puis les correspondances partielles, puis les clés de restauration dans l'ordre.
2. Comprendre la portée : la même documentation indique qu'une exécution peut restaurer les caches de sa propre branche ou de la branche par défaut (et de la branche de base pour les pull requests), jamais de branches sœurs ou filles. Réchauffer le cache de la branche par défaut à chaque fusion afin que les branches de fonctionnalité en héritent.
3. Mettre en cache le répertoire de téléchargement du gestionnaire de paquets plutôt que l'arborescence installée, sauf si l'installation est une fonction pure du fichier de verrouillage.
4. Pour les images, exporter explicitement le cache BuildKit : la page citée sur les backends note qu'à la différence du cache local toujours actif, les backends externes doivent être exportés avec --cache-to et importés avec --cache-from ; utiliser type=registry avec mode=max pour conserver les étapes intermédiaires, et importer à la fois le cache de la branche et le cache principal.
5. Ordonner les instructions du Dockerfile du plus rarement au plus fréquemment modifié, comme le recommande la page citée sur l'invalidation, car invalider une couche invalide tout ce qui suit ; la page indique aussi que les sommes de contrôle de COPY ignorent mtime.
6. Ne jamais écrire de secrets ni de jetons dans des chemins mis en cache : la documentation GitHub indique que le contenu du cache n'est ni signé ni vérifié, et que quiconque peut ouvrir une pull request peut lire les caches de la branche de base. Restreindre les écritures de cache aux déclencheurs de confiance (push, planification) et garder les workflows à déclencheur non fiable en lecture seule.
7. Surveiller l'éviction : la documentation donne une valeur par défaut de 10 Go par dépôt et la suppression des entrées non consultées depuis 7 jours ; des caches surdimensionnés dégradent les performances (thrashing).
8. Reconstruire sans cache selon une planification (--no-cache, ou une clé comportant un composant de date) pour détecter une dérive de dépendances masquée par un cache chaud.

Résultat attendu

Un cache atteint (hit) sur des fichiers de verrouillage inchangés ; un quasi-hit après un petit changement du fichier de verrouillage ; des résultats de build identiques avec ou sans cache ; aucun chemin du cache qu'une pull request de fork puisse empoisonner pour une exécution privilégiée.

Limites et base de vérification

Le bénéfice du cache dépend de la vitesse réseau par rapport à la durée d'installation, et n'est avancé sous aucune forme chiffrée. La mécanique suit la documentation GitHub et Docker citée ; d'autres systèmes d'intégration continue cantonnent et évincent différemment.