Point stabilité, mise à jour des dépendance & qualité de code

@VonOx Je trouve que le temps de build actuel des PR est vraiment long (quasi 20-25min), ce qui rend les merge multiple vraiment long.

Actuellement, pour merge 3 PR, si je fais ça propre en mergeant chaque PR une par une pour avoir un commit clean, il me faut 1h30, peu importe le contenu des PRs et sans compter le temps de review ^^

Du coup j’ai investigué, j’ai trouvé une première piste d’optimisation: mieux paralléliser les tâches.

Genre la tâche de “build front + Docker magic” n’ont en fait pas besoin de la tâche “test-server” (pour une PR je parle, sur master on veut que les tests passent avant de faire un Docker build, mais ici peu d’intérêt), donc je me demande si on pourrait enlever la dépendance?

J’ai fais une PR:

https://github.com/GladysAssistant/Gladys/pull/1104

La logique pour moi au départ c’était que ça servait à rien de build front et docker si les tests fail, d’où la séquence.

Comme tu veux !

Oui je comprend la logique, sauf qu’au final mieux vaut tout lancer en même temps, de toute façon on aura le compte rendu final à la fin.

En mettant tout en parallèle, on a un temps de tests total de 12 minutes en général, c’est encore beaucoup mais c’est moitié moins :slight_smile: Ca change beaucoup en vrai pour moi. 25 minutes de build j’ai l’impression d’être totalement improductif, je passe mon temps à attendre ^^

Pour info, j’ai mis à jour les dépendances (principalement backend, un peu frontend mais tant qu’on a pas les tests c’est dur), et j’ai rajouté sur Github action une étape d’audit de sécurité des dépendances.

Cf

https://github.com/GladysAssistant/Gladys/commit/fecd2e751b267c3c6ab0beb443cb85aaf3ba5030

1 Like

Pour cypress, je pense qu’on a une bonne base de travail, l’inscription et la page bluetooth (appels reels + mocks) sont testés.
Une question me pèse : comment faire vivre ces tests dans les PR ?
Donc je dois voir si la couverture de tests peut se faire avec cypress.

Tu parles du reporting a la codecov?

Yes je pense qu’il faut du code coverage comme pour le backend :slight_smile:

Bon ça devient compliqué, le plugin de code coverage utilisé par cypress se base sur une version de babel 7.x, mais preact-cli 2.x force la version de babel à 6.x… je commence à transpirer…

Pour répondre à ce problème, j’ai fait une migration “temporaire et rapide” de preact-cli en v3, et la j’ai un beau rapport

(screenshot coupé)

Je pense qu’il va donc falloir

  1. faire un max de couverture “a l’oeil” avec cypress
  2. [tests mergeables (avec ci)]
  3. faire la migration preact (pas si simple)
  4. activer la couverture cypress
  5. compléter la batterie de tests cypress
  6. quand la couverture est satisfaisante, merger la migration preact et la couverture
1 Like

outch !! la migration preact va être costaud, j’ai essayé plusieurs fois j’ai sué, c’est vraiment pas obvious :stuck_out_tongue:

Sinon dans l’idée ça me va, tu veux de l’aide pour la migration preact? si tu bloque sur quelque chose dis nous :slight_smile:

Je veux bien qu’on partage les tâches oui.
Pour la partie tests cypress, seul, je vais prendre un temps fou. Je me demande s’il ne faudrait pas que chaque dev prenne le sujet en main histoire de se “former”, et de tester au moins leurs services.
Sinon oui ce serait bien de commencer la migration preact en parallèle, et de noter les points critiques, pour s’assurer qu’on les couvre bien avec cypress.

Je suis d’accord!

@contributors Pour information si vous n’avez pas déjà vu, @AlexTrovato travaille sur l’ajout de tests frontend, qui vont nous permettre de mieux surveiller les régressions frontend. On va avoir besoin de l’aide de tout le monde pour tester chaque service :slight_smile:

On s’organise comment?

Il faut déjà partir de ma version

https://github.com/GladysAssistant/Gladys/pull/1086

et je pense qu’il faut merger au fur et à mesure sur cette branche.
Pour chaque service testé, faire une PR non pas vers master mais vers cette branche (si c’est possible) et merger au fur et à mesure.

Je reste bien entendu disponible en cas de question / blocage, les exemples déjà devraient suffire pour compléter la batterie de tests, mais c’est fort probable que de nouveaux cas non “réfléchis” arrivent.
Je pense par exemple au WebSocket que je n’ai pas exploré.

De mon côté, je conserve ma branche “migration preact 3 temporaire” avec couverture, je pourrais faire tourner la couverture en local pour signaler aux contributeurs s’il manque une “grosse” partie.
On affinera / complétera la couverture une fois la migration validée, car sur ma branche de migration temporaire, beaucoup de fonctionnalités sont HS.

@pierre-gilles je sais que ton temps est précieux, donc je veux bien prendre la partie “core” en plus de mes services, mais je ne pourrais certainement pas couvrir la partie gateway.
Si tu tiens à participer pour te “former”, on peut partager.

2 Likes

Juste une info supplémentaire.
Pour chaque “nouveau” test, il faut générer une token jwt via /login, et on arrive rapidement à cette erreur “Status: 429 - Too Many Requests”.
Il faudra potentiellement ajouter une config pour désactiver ce check côté server.

Ce problème arrive lors de la création des tests, a chaque nouveau test, nouveau run, on repart de zéro (lors de l’exécution de TOUS les tests, le token généré la 1ere fois est conservé tout le long).
C’est plutôt contraignant.

Est-ce que c’est réalisable de vérifier la variable NODE_ENV et désactiver la vérification du nombre de requêtes effectuées si NODE_ENV=development ?

Pourquoi tu récupère pas un jwt juste au démarrage des tests (une sorte de before() comme avec mocha je sais pas si ça existe?)

Ca me parait lourd de faire un login a chaque test !

Je pense ça serait bien que je me forme aussi! Je viendrait en renfort une fois que j’ai finis les sujets en courts (zigbee2mqtt et cie)

@pierre-gilles lors que tu développes les tests, et que tu enregistres ton nouveau test, Cypress est rechargé (comme le front avec nodemon), et repart donc de zéro.

Dans le cas où tu lances tous les tests d’un coup, ce token est bien stocké en variable d’env de Cypress,
mais c’est vraiment lors de la phase de dev des tests, où tu avances “pas à pas” que le problème apparaît, car il est très difficile d’écrire un bon test “graphique” du 1er coup, et même si c’est le cas, il faut pouvoir tester chaque test après son écriture, donc rafraichir l’env Cypress, donc générer de nouveau un token.

Bon, après avoir joué toute la matinée avec, ça ne semble pas être un vrai problème, mais c’était plutôt dû à un bug dans les commandes “spéciales” cypress-gladys (helpers) que j’avais mis en place pour gérer le token :slight_smile:

1 Like

Du coup j’ai réussi à utiliser les WebSocket (pour forcer/simuler un événement).

Autre info, suite à la vérification des vulnérabilités des dépendances npm, le build ne passe plus à cause de sequelize-cli et nyc : https://www.npmjs.com/advisories/1654.

Pour suivre la progression de la couverture Cypress, j’ai créé un projet GitHub.