Caches

Une compilation passe une bonne part de son temps à télécharger des dépendances et à recompiler ce qui n’a pas changé depuis le dernier run. Un cache garde un répertoire, comme les crates téléchargées ou un répertoire de compilation, pour que les runs suivants repartent de là.

Fonctionnement des caches

Un cache est un répertoire enregistré sous un nom, pour les runs de votre organisation. Chaque enregistrement en crée une nouvelle version, et les runs restaurent la dernière enregistrée : un cache suit ce que les runs construisent. Quand deux runs enregistrent le même nom en même temps, celui qui termine le dernier l’emporte. Quand un run demande un nom qui n’existe pas encore, il continue avec un répertoire vide, et un avertissement dans ses logs.

Un enregistrement qui contient exactement la version actuelle ne garde rien de nouveau : enregistrer après chaque run ne coûte pas de stockage quand rien n’a changé. Une version remplacée est supprimée une heure plus tard, une fois terminés les téléchargements déjà commencés.

Un programme peut aussi nommer un cache d’après ce dont il dépend, par exemple cargo- suivi d’une empreinte de Cargo.lock, et restaurer un autre nom, comme cargo, quand celui-là n’existe pas encore : ce repli est laissé au programme.

Les runs restaurent et enregistrent les caches avec le jeton de la machine qui les exécute, pendant leur exécution. Les archives sont vérifiées par leur SHA-256 avant d’être utilisées : une archive modifiée dans le stockage n’est jamais extraite. Chaque restauration est enregistrée sur son run, même manquée, avec le nom demandé, la version restaurée et son empreinte.

Les runs publics ont leurs propres caches. Les caches écrits par des runs publics, et par les runs qu’ils lancent, ne sont lus et écrits que par des runs publics, et les autres runs gardent les leurs. Ce que met en cache la merge request d’un fork reste hors des runs privés, et ce que met en cache un run privé reste hors des logs publics.

Portées de cache

Sans portée, tous les runs privés de l’organisation lisent et écrivent les mêmes caches : n’importe lequel peut écrire un cache que les autres restaurent ensuite pour compiler. Une portée de cache garde des caches à part, avec un jeton qui lui est propre (cad_cs_...).

Un run demandé avec le jeton d’une portée ne lit et n’écrit que les caches de cette portée, comme les runs qu’il lance. Les runs sans jeton utilisent les caches par défaut de l’organisation. Qui détient le jeton écrit les caches de la portée : ne le donnez qu’aux runs à qui vous confiez ce que les runs de la portée construisent. Les programmes ne le voient jamais : la demande de run le porte, et les programmes nomment seulement des caches, si bien que le même programme tourne dans une portée ou sans.

Une portée peut être lisible sans portée : un run sans jeton qui ne trouve pas un nom dans les caches par défaut le restaure alors depuis cette portée, sans jamais y écrire. Ces runs partent de ce que les runs de la portée ont enregistré au lieu de partir de rien. Les valeurs révélées de secrets sont refusées dans les caches, mais tout le reste des caches de la portée devient lisible par le code que ces runs exécutent : c’est désactivé par défaut.

Un jeton de portée trouvé dans un lieu public est révoqué aussitôt, et les caches de la portée sont supprimés, puisque quiconque détenait le jeton a pu les écrire. Les runs sont refusés avec lui jusqu’à ce que la portée reçoive un nouveau jeton, et les runs lancés avant la fuite n’atteignent plus jamais la portée.

Dans un programme

Les programmes restaurent et enregistrent des caches avec l’espace work/cache de Mélodium, et les étapes du package cicd prennent un cache à restaurer avant leurs commandes et à enregistrer une fois qu’elles réussissent. Un cache est un répertoire de n’importe quel système de fichiers que le programme atteint, celui du moteur ou le volume d’un exécuteur. Il est archivé, compressé, vérifié et envoyé pendant sa lecture, et restauré de la même façon dans un répertoire qui remplace le précédent une fois son empreinte vérifiée.

L’enregistrement refuse une archive contenant une valeur que le moteur a révélée d’un secret, dans un fichier ou dans un nom.

Gérer les caches

La page Stockage du tableau de bord, sous Ressources, liste les caches de l’organisation, les plus récemment utilisés d’abord : nom, portée, taille de la version actuelle, nombre de versions, dernière utilisation, création, et le run qui a écrit la version actuelle. Les caches écrits par des runs publics portent une marque. Les administrateurs et les opérateurs suppriment des caches avec toutes leurs versions : les runs qui demandent un nom supprimé le manquent, et le prochain run qui enregistre ce nom l’écrit à nouveau.

La page de chaque run liste les caches qu’il a demandé à restaurer, dans l’ordre : restaurés, avec la portée d’où ils viennent, ou manqués.

La même page liste les portées de cache, avec leurs caches. Les administrateurs et les opérateurs créent des portées, changent leur description et leur lecture par les runs sans portée, et leur donnent un nouveau jeton ; le jeton n’est affiché qu’une fois. Les administrateurs suppriment des portées, avec leurs caches.

Les caches comptent dans le stockage géré de votre offre, et les versions utilisées le moins récemment sont évincées quand il faut de la place, les versions remplacées d’abord. Avec votre propre stockage, les caches vont dans son bucket principal, sans quota. Les caches restent sur le principal : faciles à reconstruire, ils sont exclus de la réplication.

Pour aller plus loin

• Artefacts de run : garder ce qu’un run a produit.
• Stockage : les quotas, et garder les caches dans votre propre bucket.
• Clés : le format des jetons de portée de cache, et ce qui arrive à un jeton qui a fuité.
• L’espace work/cache de la référence Mélodium.