Le Cache CercleCI Cache Key Bug qui sert silencieusement vos dépendances stales

Votre pipeline CircleCI est vert. Chaque emploi passe. Et pourtant, votre application fonctionne contre une version de dépendance qui n'a pas été expédiée depuis un mois — personne ne l'a commis, personne ne l'a heurtée, il est simplement apparu tranquillement dans la production. Si vous avez poursuivi un bug comme celui-ci, le coupable n'est presque jamais votre code. C'est ta clé de cache. C'est cinq minutes de lecture et quinze minutes de réparation. Quick Win vendredi, déployé sur votre . Le mode d'échec La mise en cache de la dépendance de CircleCI fonctionne sur un simple contrat : vous calculez une clé à partir de quelque chose qui change lorsque vos dépendances changent (généralement un total de vérifications du fichier de verrouillage), et vous sauvegardez/restaurer un cache lié à cette clé. Le contrat se divise en trois manières spécifiques, extrêmement communes: Vous vous trompez de dossier. semble raisonnable jusqu'à ce que quelqu'un heurte une dépendance transitoire via sans toucher. Le bilan ne bouge pas. CercleCI repart avec joie la semaine dernière. CircleCI essaie d'abord votre clé primaire, puis tombe dans l'ordre, et le premier est un match de préfixe contre les entrées de cache existantes — pas "donne-moi le plus récent match exact." Si votre liste restart keys est trop grossière (par exemple seulement), vous pouvez restaurer un cache construit à partir d'une branche complètement différente, avec un fichier de verrouillage complètement différent, et le travail ne échouera pas. Il n'installera rien tranquillement (cache frappé, voit les modules sont "là") ou fonctionne contre les mauvaises versions. Il n'y a pas de sortie de version. Lorsque vous devez inévitablement forcer le cache de tout le monde à invalider — une entrée de cache corrompue, une migration de gestionnaire de paquets, un changement de format de fichier de verrouillage — il n'y a pas de moyen bon marché de le faire, parce que le format de clé n'a jamais été conçu avec un buster manuel à l'esprit. Chacun d'eux échoue silencieusement. Pas d'erreur dans les journaux. Juste une construction qui a fonctionné avec l'état stalle, et un rapport de bogue trois jours plus tard que personne ne peut reproduire localement parce que local est bien. La correction Remplacez ce à quoi ressemble votre bloc cache actuel avec cette forme : Quatre modifications spécifiques, chacune fixant un des modes de défaillance ci-dessus : Contrôlez le fichier de verrouillage, pas le manifeste. / / / — quoi qu'il arrive en fait à épingler vos versions résolues. C'est le seul fichier où "rien n'a changé" est une déclaration vraie sur votre arbre de dépendance. (ou , ou ) comme la commande d'installation, toujours. C'est le filet de sécurité pour les modes d'échec que vous n'avez pas encore corrigé : si le cache restaure quelque chose d'impasse, une installation gelée refuse de procéder silencieusement avec un fichier de verrouillage mal adapté au lieu de le réconcilier tranquillement. Tu veux que ce boulot soit rouge, pas vert avec le mauvais arbre. Ordre de la plupart au moins spécifique, et d'arrêter un niveau à court de "matches n'importe quoi." Branch-scoped match exact premier, branche-scoped préfixe second, préfixe global dernier comme un véritable dernier recours pour une toute nouvelle branche. Ne vous contentez pas d'avoir votre seul repli — c'est la ligne qui permet à une branche de restaurer un cache à partir d'un fichier de verrouillage différent entièrement. Bump la version principale jeton ( → ) chaque fois que vous avez besoin d'une ardoise propre. C'est votre cache manuel. Parce qu'il est cuit dans la clé elle-même, forçant l'invalidation pour tout le monde est un PR en une ligne, pas un ticket de support pour CircleCI ou un voyage à travers les paramètres du projet UI à nue caches à la main. Vérifier que ça a vraiment marché Ne pas envoyer le changement YAML et faire confiance. Ajoutez une étape d'affirmation d'une ligne pendant une semaine pendant que vous confirmez votre comportement : Ajustez le nom du paquet à n'importe quelle dépendance vous a mordu avant, ou quoi que votre équipe voudrait le plus savoir expédié la mauvaise version. Si ce grep échoue jamais, votre cache et votre fichier de verrouillage ont divergé — et maintenant il échoue fort, en CI, au lieu de calme, dans la production. Le piège monorepo Si vous êtes sur un espace de travail Yarn/npm ou un monorepo avec plusieurs fichiers verrouillables, la fonction checksum ne fait que hacher ce que vous lui dites. à la repo root n'attrapera pas de changement aux propres dépendances d'un paquet d'espace de travail à moins que votre gestionnaire de paquet écrit cette résolution dans le fichier de verrouillage racine (la plupart le font, mais la vérifient pour la vôtre). Si vous avez niché des fichiers qui ne sont pas supposés t