repères
La limite de cache de 10 Go est le véritable goulot d'étranglement du CI
Nous avons instrumenté 40 000 exécutions de flux de travail. Le comportement du cache prédisait mieux le temps d’horloge murale que le nombre de vCPU, et la plupart des équipes dépassent le plafond sans jamais s’en rendre compte.
{auteur} · {rôle} · 2026-07-02 · 9 min de lecture
Il existe un mode d'échec dans GitHub Actions qui ne produit aucune erreur, aucun avertissement et aucune ligne de journal. Votre référentiel traverse 10 Go de cache, les entrées les moins récemment utilisées commencent à être expulsées et à partir de ce jour, une partie de vos exécutions démarre tranquillement à froid.
Personne n'est bipé pour ça. La construction passe toujours. C'est juste plus lent, toujours, et au moment où quelqu'un enquête, le changement date de six mois.
Ce que nous avons mesuré
Sur 40 000 exécutions sur des référentiels activés, nous avons enregistré le taux de réussite du cache, la durée de restauration, la taille du coureur et la durée totale de l'horloge murale. Deux choses ressortent.
La deuxième conclusion est la plus exploitable : en dessous d’un taux de réussite du cache d’environ 80 %, l’ajout de vCPU a à peine modifié la durée totale du pipeline. Les équipes achetaient des machines plus grosses pour compenser les caches froids, ce qui est proche du moyen le plus coûteux de résoudre ce problème.
La vitesse de restauration compte autant que le taux de réussite
Un cache qui prend quatre minutes à restaurer et économise trois minutes de travail est une perte nette, et il affichera un taux de réussite de 100 % tout en vous faisant perdre du temps. Nous avons vu plusieurs référentiels exactement dans cet état.
Que faire à ce sujet
Votre prochain build pourrait être deux fois plus rapide, pour moitié prix
Commencez gratuitement. Repartir tient à la même ligne, et nous publions ce diff aussi.