GitHub Actions cache-mode : vérifier les permissions de cache derrière un CI au vert
Si votre CI se termine au vert mais télécharge à nouveau les dépendances lors de l'exécution suivante, le premier réflexe est souvent de corriger les clés de cache. Désormais, il faut également vérifier si la sauvegarde n'a pas été ignorée en raison des permissions. En effet, le simple fait qu'un workflow réussisse ne garantit pas qu'un cache ait été créé.
GitHub a annoncé la disponibilité générale de cache-mode le 10 septembre 2026. Sur tous les forfaits de github.com, vous pouvez définir l'accès au cache au niveau du workflow ou du job. En allant plus loin que l'article précédent qui traitait de la valeur par défaut en lecture seule, nous nous concentrons cette fois sur la configuration explicite et les méthodes de vérification.
Fonctionnalités confirmées : quatre combinaisons de restauration et de sauvegarde
read autorise uniquement la restauration, tandis que write autorise la restauration et la sauvegarde. write-only n'autorise que la sauvegarde, et none bloque les deux. Le premier point de contrôle consiste à ne pas confondre le nom write avec un mode exclusivement réservé à la sauvegarde.
La valeur déclarée au niveau d'un job prévaut sur la configuration globale du workflow. En revanche, lors de l'appel d'un reusable workflow, celui-ci ne peut pas recevoir des permissions d'accès supérieures à celles autorisées par l'appelant. Ne déterminez pas les permissions réelles de l'ensemble de l'exécution en lisant simplement la déclaration d'un seul fichier.
Une exécution au vert n'est pas une preuve de sauvegarde
La documentation officielle explique qu'une opération de cache non autorisée consigne un message informatif dans les logs et poursuit son exécution. Une restauration bloquée est traitée comme un cache miss, et une sauvegarde bloquée n'est pas effectuée. Le point clé de l'observabilité réside dans le fait que le workflow lui-même n'échoue pas.
Il est donc judicieux de séparer vos enregistrements d'exploitation entre le statut de succès de l'exécution et le résultat du cache. Vérifiez au sein d'une même exécution quel événement a déclenché le run, quel mode a été appliqué, si la restauration a réussi et si la sauvegarde a été ignorée. Il s'agit d'une approche opérationnelle suggérée sur la base des descriptions officielles des fonctionnalités, et non d'une nouvelle fonctionnalité de tableau de bord fournie automatiquement.
Créer un petit tableau de permissions avant l'application
Parcourez les workflows réels de votre dépôt pour identifier les jobs qui produisent du cache et ceux qui en consomment. Il n'est pas nécessaire d'attribuer les mêmes permissions à un job préparant les dépendances sur une branche de confiance, à un job testant des modifications externes et à un job validant les livrables de déploiement.
Pour chaque job, écrivez deux phrases : ce job doit-il lire un cache existant ? Le résultat de ce job peut-il être laissé pour que la prochaine exécution le lise ? Si aucun des deux n'est nécessaire, vous pouvez remettre en question l'habitude systématique d'associer un cache. Cependant, la configuration réelle doit être décidée en fonction des limites de confiance et de l'architecture de build de votre dépôt.
Expérimentation minimale : job consommateur en lecture seule
Par exemple, dans un workflow de test, spécifiez cache-mode: read au niveau racine et vérifiez qu'aucune surcharge spécifique à un job n'existe. Comparez si les résultats des tests avec cache sont identiques à ceux obtenus sans cache. Le cache ne devant être qu'un moyen auxiliaire pour réduire le temps d'exécution, si l'exactitude varie en l'absence de cache, il faut d'abord vérifier les hypothèses de build.
Le critère de réussite de cette expérimentation ne se limite pas à une ligne verte de succès dans le CI. Vous devez être capable d'expliquer la tentative de restauration et l'omission de la sauvegarde, puis pouvoir valider à nouveau lors de l'exécution suivante avec les mêmes entrées. Consigner ensemble les commits avant et après l'expérience, le déclencheur, la configuration effective et l'emplacement des logs permettra à vos collègues de reproduire facilement votre évaluation.
Pour les reusable workflows, lire jusqu'au chemin d'appel
Même si vous avez défini des valeurs par défaut sécurisées dans un workflow partagé, vous devez examiner conjointement l'appelant et les configurations individuelles des jobs. Le fait que plusieurs dépôts appellent le même fichier ne signifie pas qu'ils s'exécutent avec les mêmes permissions.
Lors de la revue de code, suivez l'ordre en partant de l'appelant, puis la déclaration de cache du job, et enfin le workflow appelé. Si les permissions attendues diffèrent des logs réels, trouvez la source de la configuration avant de rendre les clés plus complexes. Il s'agit d'une suggestion visant à réduire le temps de diagnostic dans les organisations utilisant largement la réutilisation, et non d'un chiffre mesuré d'amélioration des performances.
Exceptions à surveiller et ordre d'application
Spécifier write ou write-only sur des événements à faible niveau de confiance tels que pull_request_target peut outrepasser la restriction par défaut en lecture seule et augmenter le risque d'empoisonnement du cache. Dans ce cas, GitHub ajoute une annotation d'avertissement. Il faut éviter d'élargir les permissions d'écriture simplement pour faire disparaître cet avertissement.
Inversement, choisir de bloquer tout le cache a également un coût. Comme les temps de téléchargement et de build peuvent augmenter, comparez directement les temps d'exécution sur un job représentatif avant d'étendre la portée. Plutôt que de promettre des gains de performance sur la base d'estimations chiffrées, il est préférable que l'équipe définisse ensemble les restrictions de sécurité nécessaires et les latences acceptables.
Questions que l'équipe doit se poser dès maintenant
La tâche d'aujourd'hui ne consiste pas à ajouter en bloc la nouvelle configuration sur l'ensemble des dépôts. Il s'agit d'identifier les producteurs et les consommateurs de cache dans un workflow critique, de noter leurs permissions et de vérifier les preuves de restauration et de sauvegarde sur une exécution. S'il s'agit d'un job de déploiement, gardez les modifications modestes afin que le responsable puisse lire les logs et vérifier la conformité avec les attentes.
Une question courante en pratique est de savoir pourquoi le CI a réussi alors que l'étape de sauvegarde a été ignorée. Cet article explique cette confusion en s'appuyant sur le comportement officiel, sans prétendre s'appuyer sur des sondages communautaires distincts ou des taux d'incidents universels. Lors de l'adoption d'une nouvelle fonctionnalité, vérifier séparément les résultats de performance et les résultats de permissions vous permettra de catégoriser plus précisément le prochain problème de cache.