Monitoring du code de ZdS

coveralls, landscape et ces machins là

a marqué ce sujet comme résolu.

J'aimerai qu'on discute un peu des outils d'analyse de code, si vous me le permettez.

Pour commencer, je trouve que faire ça est une bonne idée, et je n'ai absolument rien contre. Ce qui me fait par contre plus douter, c'est le comportement des deux outils de monitoring actuel, coveralls et landscape.

Parlons de coveralls, pour commencer. Depuis peu, nous somme gratifié d'un magnifique 47% de couverture. En cause ? Une petite PR de rien du tout qui, fait son job et qui ajoute un nouveau TU. C'est pas moi qui le dit, c'est Travis. On dirait qu'il vient de se rendre compte que le module article existe, que sa couverture est dégueulasse (ah bon ?) et ça, ça à l'air de nous coûter 32% presque gratuitement. Ouch ^^

Mais de manière générale, je ne pige pas bien quand coverall s'active: des fois on un un message qui nous explique qu'on vient de mettre en l'air la couverture (en prenant pour référence l'état actuel de dev, je crois), des fois on peut faire 3 commits sans en avoir la moindre nouvelle. On dirait qu'on en à plus de nouvelle de ces temps-ci, mais je peux sortir une liste de PR ou coveralls n'est jamais passé (les dernières PRs de firm1 sont de bon exemples).

Quand à landscape, c'est différent. Selon lui, nous sommes à 90% de santé. Bien. Ce qui m'étonne un peu plus avec lui, c'est que des fois il tente de vérifier la santé avec la branche de dev ET la branche de release, va savoir pourquoi (par exemple ici et le post juste en dessous), puis ce que je ne comprend pas non plus, c'est qu'il arrive à trouver des problèmes et des solutions dans des PRs qui changent uniquement les templates, alors que c'est absolument pas son domaine (et c'est pas le seul exemple, c'est pas un cas isolé). Puis, par exemple, landscape trouve des solutions à ces propres problèmes tout seul (← le lambda fautif est toujours là, c'est juste qu'il n'as plus l'air de poser problème).

Bref, quand je vois tout ça (et ça fait un certain temps que je le vois, c'est pas soudain), je suis un peu étonné des réponses données par de tels services. Une fois encore, j'en comprend l'intérêt, mais si c'est pour changer d'avis à chaque commit (et parfois de manière assez abrupte, comme j'ai pu le montrer), que valent-ils ? Est ce que voir un "380 new problems were found" ou "Coverage decreased (-18.3%)" est inquiétant ou juste un "hoquet" du système qui se rend compte qu'il avait pas regardé à tout ?

Bref, voilà un peu mes remarques et questions. À vous :)

Pour coveralls, ça fait un certain temps qu'il nous annonce qu'on va se manger une perte de couverture, qui est effectivement arrivée hier. Je remonterais ça à quelques semaines, mais j'arrive pas à trouver quand ça à commencé. C'est firm1 le spécialiste de cet outil là, donc j'attend son avis éclairé, mais si y'avais moyen de tracer ça a un commit en particulier, ça aiderai probablement.

Quand à lanscape il à l'air de s'être calmé et de ne plus trouver de "nouveaux problèmes"

Tout d'abord en ce moment précis on a un bug qui s'est visiblement glissé dans les tests puisque la dev ne build pas. Le fait qu'on crée à plusieurs endroit dans les tests un groupe "bot", fait que mysql détecte du doublon. La cause ici est que travis n'a pas été relancé sur les PRs entre chaque merge (cf. la vague de merge d'hier), la bonne nouvelle est que je peux fournir un fix de ce problème dans la journée.

Maintenant le problème des outils de monitoring.

Coveralls

En ce qui concerne Coveralls, j'ignore encore si c'est a cause du paramétrage, mais il ne prévient maintenant qu'en cas de perte de pourcentage de couverture. Ce qui n'est pas mauvais en soit, le problème soulevé par pierre est que depuis qu'on lance les tests en parallèle, coveralls ne reçoit pas toutes les données de couverture en même temps. Nous avons 3 environnement de tests, et 2 qui sont susceptibles de générer de la couverture. Quand coveralls reçoit son premier rapport de couverture, s'il ne reçoit pas le deuxième avant un certains temps (je ne le connais pas exactement), il considère qu'il n'attend plus rien. Or les environnements ne terminent pas toujours leurs tests en meme temps.

Ceci dit, si vous ne l'avez pas encore remarqué, quand le rapport de couverture est envoyé à Coveralls, il met à jour tout seul le taux de couverture et bien souvent on reçoit un message de perte de couverture et 2 minutes plus tard en allant sur github ce n'est plus le cas.

Landscape

Landscape a une façon un peu spéciale de traiter les PRs et ce module est encore expérimental chez eux. En fait quand on fait une PR, celui-ci traite la la branche en question plutôt que la PR et ça change tout.

Pour bien faire il devrait traiter la branche dev+diff, et ainsi son analyse de code serait correct. Mais aujourd'hui il traite la branche de départ uniquement. Ce qui signifie en gros que si votre branche n'est pas totalement à jour avec les commits de dev, il vous signalera des erreurs qui n'existent plus dans dev.

Voilà en gros, ce que je peux en dire.

Après si les outils sont très dérangeant on peut désactiver au moins les bots (surtout celui de landscape qui ne sert pas beaucoup -en tout cas pas à moi- )

travis Django est pas compatible travis/coveralls?

Fix'd

Du reste, je viens de comprendre ce qui me perturbe (merci Firm1). Prenons l'exemple de ma PR de documentation :

  • Effet de cache puissance 42 :

(avant CTRL+F5), perte de 18% de couverture

  • Données incohérentes lorsqu'on s'affranchit du cache (je crois) :

Après CTRL+F5: gain de 0.01% de couverture (ce qui, soit dit au passage, n'as pas de sens, c'est une PR de documentation)

  • Mail qui corobore la première version:

(mail de GitHub)

Donc euuuh … Je dois croire quoi à quel moment ?!?

+5 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte