Cache de compilation, CI, et runners

Tools
1

Rien que le cache de compilation de duniter-v2s on peut compter 60 Go. Et les projets Rust en général utilisent énormément d’espace de cache.

2

Attention, si par “cache” ici tu appelles les artefacts ou le contenu de “cache” dans les .gitlab-ci.yml alors (il me semble que) c’est stocké côté gitlab (donc doppler)

Par contre ça veut dire effectivement qu’au runtime on a besoin de pas mal de place, ce qui exclut de n’avoir “que” 160GB

1 Like
3

Tu veux dire que ça fait 60 Go qui transitent sur le réseau à chaque fois que la CI tourne sur un runner ?

4

Oui. Si le cache fait vraiment 60GB (il est quand même compressé), et si j’ai bien compris de quoi tu parles

5

Je bouge ça en dehors de la discussion initiale parce que j’aimerais bien creuser un peu cette CI :smiley:

Là sur ma machine :

  • 5,5G .rustup/
  • 7,0G .cargo/
  • 46G duniter-v2s/target/
6

ok :stuck_out_tongue:

Pour ce que j’en sais :

  • Gitlab va normalement conserver tous les caches “long terme”. Parce que ce cache peut êtr epassé d’un runner à l’autre, donc il ne peut pas être conservé “localement” sur un runner.
  • Chaque runner conserve lui-même des caches, sous forme de volumes docker (c’est les 43GB de mon message précédent). Peut être qu’en fait ces “caches” ne sont pas des caches mais des trucs à nettoyer régulièrement et ce n’est pas fait correctement.
7

Le dossier target contient les fichiers de compilation incrémentale. Les conserver permet de compiler plus rapidement plus tard (uniquement si les crates utilisées ou leurs dépendances n’ont pas changé, et si la version de Rust n’a pas changé), mais cargo ne le nettoie pas automatiquement donc les vieux fichiers s’accumulent.

S’il y a un compromis à faire, je dirais qu’on peut conserver un target pour chaque PR active. Compiler successivement des branches différentes avec un même target est moins rapide et augmente en taille plus vite.
Une autre solution est de donner à chaque CI de PR une snapshot du dernier target de master.

En tout cas il vaut mieux le vider à chaque fois qu’on met à jour un grand nombre de dépendances ou Rust (par exemple, la màj de Substrate).

Un autre cache est celui dans ~/.cargo, qui contient le code des crates téléchargées. Le conserver permet de ne pas devoir retélécharger les crates (l’usage hors-ligne est alors possible).

2 Likes