Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.
Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.
Mais ça c'est quand c'est bien fait.
Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)
Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.
Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..
# Attention au stats
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal A propos de packaging et de LuaUnit. Évalué à 5.
Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.
Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.
Mais ça c'est quand c'est bien fait.
Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)
Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.
Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..