• [^] # Re: En cache?

    Posté par (site web personnel) . En réponse au journal Combien d'utilisateurs pour LuaUnit ?. Évalué à 4.

    Perso, pour l'intégration continue, j'utilise travis-ci et AppVeyor qui servent tous les deux des milliers de builds par jour (voire peut-être des millions, il faudrait vérifier). Dès que le build est fini, l'image docker est mise à la poubelle pour démarrer un autre build d'un autre projet.

    Donc autant sur mon poste, luarocks pourrait utiliser un cache local ou un proxy, autant sur ce type d'instance partagé, c'est irréaliste.

    Par contre, il est possible de configurer travis et AppVeyor pour avoir explicitement un cache de certaines données. Mais cela demande un léger effort, qui ne vaut pas forcément les 5s que tu va gagner sur ton build par rapport à une installation simple.

    De plus, certains devops sont attachés à démarrer avec un environnement de build le plus vierge possible et donc n'aiment pas l'effet mémoire introduit avec un cache.

    Mais tu as raison sur le gâchis de ressource. Je suis persuadé que tous les gestionnaires de paquets (pip, cargo, npm, luarocks, ...) doivent fournir une part très importante de leurs ressources à de la CI qui pourrait les économiser.

    Sur mes projets, j'ai fait l'effort en tout cas.