@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?
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 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.
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.
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…
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.
@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
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.
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.
@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
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.
Ca change beaucoup en vrai pour moi. 25 minutes de build j’ai l’impression d’être totalement improductif, je passe mon temps à attendre ^^
