vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-08-28T12:59:53+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2254Vitesse des tests et lancement Stanford2017-08-28T12:59:53+02:00Mathieu GiraudVitesse des tests et lancement StanfordUne tripotée de tests `should-get` utilisent `Stanford_S22.fasta` (et aussi `bugs/bug2224.should-get`). Au moins 15 d'entre eux n'ont aucun `-x` ou `-X`, et pourtant tous n'auraient pas besoin de tourner sur 13 000 reads. Pourrait-on met...Une tripotée de tests `should-get` utilisent `Stanford_S22.fasta` (et aussi `bugs/bug2224.should-get`). Au moins 15 d'entre eux n'ont aucun `-x` ou `-X`, et pourtant tous n'auraient pas besoin de tourner sur 13 000 reads. Pourrait-on mettre ces tests avec des `-x 100` (ou même `-x 1000`) ? Cela pourrait améliorer considérablement la vitesse de l'ensemble.
Voir par exemple e963e16.
cc @mikael-sAlgo 2017.07https://gitlab.inria.fr/vidjil/vidjil/-/issues/3027Sortir partiellement vidjil-h-examples.should-get vers un nouveau stage de test2018-06-26T10:41:01+02:00Mathieu GiraudSortir partiellement vidjil-h-examples.should-get vers un nouveau stage de testDepuis ee762649 / f7c71ba pour #2635, les tests mettent 7 minutes de plus pour se lancer deux fois sur LIL-L4.
J'avais mis dans un premier temps `-x 10000` pour que cela soit plus rapide, mais le but est bien de montrer dans l'aide des...Depuis ee762649 / f7c71ba pour #2635, les tests mettent 7 minutes de plus pour se lancer deux fois sur LIL-L4.
J'avais mis dans un premier temps `-x 10000` pour que cela soit plus rapide, mais le but est bien de montrer dans l'aide des commandes utiles en situation réelle.
Cela pourrait encore s'empirer si on en met dans `doc/algo.org` (ce qui est souhaitable).
Pour %"Algo 2017.11" cela peut aller, mais pour la suite (et surtout pour notre ~"dev-ci" régulière), il faudrait sortir ces choses longues vers un stage appelé rarement comme valgrind.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3308Précompilation des headers2018-06-26T09:37:57+02:00Mathieu GiraudPrécompilation des headers@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/issues/3307#note_100117 :
> Sinon il y a la possibilité de précompiler les headers : https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/issues/3307#note_100117 :
> Sinon il y a la possibilité de précompiler les headers : https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.htmlhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3309Makefile et vidjil.cpp2018-06-26T10:38:30+02:00Mathieu GiraudMakefile et vidjil.cppOn en a sûrement déjà parlé il y a quelques années, mais c'est toujours embêtant (surtout tant qu'on a pas #3308) que `make` recompile toujours `vidjil.cpp`, même quand c'est inutile.On en a sûrement déjà parlé il y a quelques années, mais c'est toujours embêtant (surtout tant qu'on a pas #3308) que `make` recompile toujours `vidjil.cpp`, même quand c'est inutile.Algo 2018.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3339Déplacer les tests de coverage plus loin dans le pipeline2018-07-09T10:28:00+02:00Mathieu GiraudDéplacer les tests de coverage plus loin dans le pipelineDepuis !227, unit-test est *beaucoup* plus long : certains font plus de 13 minutes alors qu'on était à moins de 3 minutes. (Pas vérifié pour les fonctionnels).
Mettre cela plus loin, vers les tests valgrind / prepare-release. (Ou même l...Depuis !227, unit-test est *beaucoup* plus long : certains font plus de 13 minutes alors qu'on était à moins de 3 minutes. (Pas vérifié pour les fonctionnels).
Mettre cela plus loin, vers les tests valgrind / prepare-release. (Ou même les mettre en manuel ?)Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3502Avoir par CI un suivi des temps des différents tests2024-01-18T10:29:12+01:00Mathieu GiraudAvoir par CI un suivi des temps des différents tests~"dev\-gitlab" se souvient déjà du temps total d'un job. C'est peut-être suffisant, mais on aimerait parfois pouvoir comparer (et tracer) l'évolution des temps d'exécution, comme ce que permet de faire Jenkins, mais aussi en comparant de...~"dev\-gitlab" se souvient déjà du temps total d'un job. C'est peut-être suffisant, mais on aimerait parfois pouvoir comparer (et tracer) l'évolution des temps d'exécution, comme ce que permet de faire Jenkins, mais aussi en comparant des branches / MR.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3546make -j 42018-10-15T18:37:49+02:00Mathieu Giraudmake -j 4Devrions-nous mettre par défaut une option pour compiler en parallèle quand c'est possible ?Devrions-nous mettre par défaut une option pour compiler en parallèle quand c'est possible ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3630gitlab-ci.yml, `parallel` voire `matrix`2021-10-20T12:16:16+02:00Mathieu Giraudgitlab-ci.yml, `parallel` voire `matrix`Depuis 11.5.
https://docs.gitlab.com/ce/ci/yaml/#parallel
Ce serait à nous de dire quoi faire en fonction de `CI_NODE_INDEX`.Depuis 11.5.
https://docs.gitlab.com/ce/ci/yaml/#parallel
Ce serait à nous de dire quoi faire en fonction de `CI_NODE_INDEX`.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4829test watir serveur; rallonger le temps pour la connection2021-08-31T10:06:55+02:00Thonier Floriantest watir serveur; rallonger le temps pour la connectionJ'ai de très nombreux tests watir serveur qui échouent à cause du temps de chargement de la page login.
Je pense qu'il faut mettre un sleep ou quelques chose du genre.
Cette erreur est particulièrement récurrente sur le test `test_sam...J'ai de très nombreux tests watir serveur qui échouent à cause du temps de chargement de la page login.
Je pense qu'il faut mettre un sleep ou quelques chose du genre.
Cette erreur est particulièrement récurrente sur le test `test_sample.rb`, qui débute pourtant de la même façon que les autres tests serveurs.
Au passage, je vais factoriser ce passage dans une fonction de vidjil_browser puisqu'elle est employée à divers endroits.
Si quelqu'un y voit une contre indication...
cc @magiraud @mikael-s @Zeudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4839Preprocess json; pouvoir les tester en CI2021-09-15T17:15:45+02:00Thonier FlorianPreprocess json; pouvoir les tester en CINous avons mis à jour `flash2.py` pour permettre la production de sortie json intégrable aux analyses.
Mais pour le moment il me semble que ce n'est pas testé.
On pourrait rajouter un test la dessus, mais il faudrait avoir une paramétr...Nous avons mis à jour `flash2.py` pour permettre la production de sortie json intégrable aux analyses.
Mais pour le moment il me semble que ce n'est pas testé.
On pourrait rajouter un test la dessus, mais il faudrait avoir une paramétrage permettant de faire appel au merger, puis charger des données mergeable, attendre le merge, lancé une analyse dessus et voir le résultat.
A réfléchir.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4878validate-links.py: asynchrone ?2021-10-12T12:27:49+02:00Mathieu Giraudvalidate-links.py: asynchrone ?
On pourrait probablement gagner du temps de build.
On pourrait probablement gagner du temps de build.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4943Couper shouldvdj en deux ?2022-01-27T12:23:45+01:00Mathieu GiraudCouper shouldvdj en deux ?Sur les domino*, `algo_shouldvdj` prend ~20 minutes, alors que les autres (surtout should) sont au plus à ~10 minutes.
Couper shouldvdj en deux permettrait d'avoir plus rapidement le résultat / de lancer plus rapidement la suite quand c...Sur les domino*, `algo_shouldvdj` prend ~20 minutes, alors que les autres (surtout should) sont au plus à ~10 minutes.
Couper shouldvdj en deux permettrait d'avoir plus rapidement le résultat / de lancer plus rapidement la suite quand c'est le cas.
Mais... #2259 / !413 ne serait-il pas bien mieux ?