vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2019-03-19T19:37:18+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3840Demander confirmation avant la sauvegarde d'analyse en tant qu'admin2019-03-19T19:37:18+01:00Thonier FlorianDemander confirmation avant la sauvegarde d'analyse en tant qu'admin@mikael\-s et moi nous sommes déjà fait avoir par un `ctrl+s` malencontreux. On pourrait dans ce cas ouvrir un modal qui demande de la confirmer manuellement pour ne pas modifier ou effacer des analyses qu'un user aurait pu faire.@mikael\-s et moi nous sommes déjà fait avoir par un `ctrl+s` malencontreux. On pourrait dans ce cas ouvrir un modal qui demande de la confirmer manuellement pour ne pas modifier ou effacer des analyses qu'un user aurait pu faire.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4614Comparer automatiquement les résultats sur certains fichiers récents ?2020-12-18T11:28:32+01:00Mikaël SalsonComparer automatiquement les résultats sur certains fichiers récents ?En fermant #1257 je me pose la question d'un mécanisme plus fin.
Quand on change de version algo, on pourrait avoir envie de lancer l'algo aléatoirement sur X fichiers récents et comparer les résultats avec la précédente version. Ça ser...En fermant #1257 je me pose la question d'un mécanisme plus fin.
Quand on change de version algo, on pourrait avoir envie de lancer l'algo aléatoirement sur X fichiers récents et comparer les résultats avec la précédente version. Ça serait une utilisation pertinente de notre Vidjil-algo-next.
Ce lancement pourrait être fait côté serveur (physique) sans que cela crée de nouveaux processes dans l'interface.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4371Pouvoir figer ou versionner les configs pour qualification2021-02-24T16:54:53+01:00Mathieu GiraudPouvoir figer ou versionner les configs pour qualificationQuelques réflexions suite à la discussion de hier: dans l'esprit d'une qualification, on doit pouvoir précisément tracer la ~"server-config".
Une possibilité est de pouvoir *figer* les ~"server-config": un champ booléen "figé".
C'est un...Quelques réflexions suite à la discussion de hier: dans l'esprit d'une qualification, on doit pouvoir précisément tracer la ~"server-config".
Une possibilité est de pouvoir *figer* les ~"server-config": un champ booléen "figé".
C'est une action manuelle, par les ~"server-admin", de figer une config. Une config figée est... figée, elle ne peut plus être modifiée dans l'interface. On pourrait toujours la dupliquer pour modifier quelque chose. Une config figée apparaît avec par exemple avec un "*" dans la liste.
Une config figée ne peut pas se supprimer dans l'interface, mais elle peut se désactiver: elle n'apparaît plus dans la liste des configs, ou en tout cas pas dans la liste principale. Concrètement, cela peut juste vouloir changer la *classification* de la config, qui elle n'est pas figée. (Et permettre d'accéder à des résultats de config, même si on ne peut plus relancer, avoir un booléen "désactivé" sur une classification, ou sur une config ?)
Peut-être peut-on tout de même renommer la config (genre "Human default (2019.05)" pour suivre les anciennes versions ?)
Autre solution évoquée: *versionner* les ~"server-config": ajouter un champ "date", un champ "previous_id", et, à chaque modification, ne pas écraser mais dupliquer. Aussi possible (génère un peu plus d'entrées quand on fait des tests)... mais ne me semble pas aussi fort que de figer (et l'usager ne se rend pas compte si on modifie quelque chose sans le prévenir).
cc @duez @flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3738Analyse statique du code C++2020-08-27T11:15:06+02:00Mathieu GiraudAnalyse statique du code C++Tiens, nous avons beaucoup de ~"dev\-tests" (et aussi une bonne compilation #1233, et des bons tests mémoire Valgrind), mais pas d'analyse statique du code.
Serait-ce pertinent de s'y mettre ?
Voir #2272Tiens, nous avons beaucoup de ~"dev\-tests" (et aussi une bonne compilation #1233, et des bons tests mémoire Valgrind), mais pas d'analyse statique du code.
Serait-ce pertinent de s'y mettre ?
Voir #2272https://gitlab.inria.fr/vidjil/vidjil/-/issues/3627Checksum des fichiers uploadés et autres ?2021-11-19T11:06:57+01:00Mathieu GiraudChecksum des fichiers uploadés et autres ?Réflexion lancée par @mikael\-sRéflexion lancée par @mikael\-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3446Tests fonctionnels sur serveurs de tests à partir de traces live2018-09-04T16:37:24+02:00Mathieu GiraudTests fonctionnels sur serveurs de tests à partir de traces liveEn lisant des choses pour #2323, je suis tombé plusieurs fois sur des choses incitant à "capture real traffic to replay offline". Cette issue est pour approfondir ce point (mais pas du tout pour débattre de #2323, merci).
C'est en lien ...En lisant des choses pour #2323, je suis tombé plusieurs fois sur des choses incitant à "capture real traffic to replay offline". Cette issue est pour approfondir ce point (mais pas du tout pour débattre de #2323, merci).
C'est en lien avec la remarque de @mikael\-s dans https://gitlab.inria.fr/vidjil/vidjil/issues/2323#note_114495 :
> Il faut des tests sur une copie de la BDD de prod (anonymisée) directement dans les branches de développement et sur `prod-server`
Ce serait déjà un bon pas de faire cela, en faisant attention aux fuites de données : si données HDS, même anonymisées, elles devront rester sur un serveur de test dans l'enceinte HDS. Une version simple serait effectivement d'y recopier la BDD et de lancer la suite de tests de #3401.
Mais pouvons-nous aller plus loin, c'est-à-dire capturer vraiment sur la prod des suites d'actions utilisateurs (avec leurs hésitations / comportements non optimaux et autres) et les rejouer en test ensuite ? Au niveau requêtes serveur, cela doit être jouable (bien plus qu'au niveau clics sur client).
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3374Stocker en base de données tous les accès2019-01-08T15:11:23+01:00Mikaël SalsonStocker en base de données tous les accès(on les a déjà dans les fichiers)
Que ce soit les accès à un sample set, mais aussi aux listes de samples ou aux listes d'utilisateurs, etc…
En lien avec vidjilnet#10(on les a déjà dans les fichiers)
Que ce soit les accès à un sample set, mais aussi aux listes de samples ou aux listes d'utilisateurs, etc…
En lien avec vidjilnet#10https://gitlab.inria.fr/vidjil/vidjil/-/issues/3154Récupérer des infos des pré-process : mécanisme2021-10-07T16:17:55+02:00Mathieu GiraudRécupérer des infos des pré-process : mécanismeVoir #2875 et #2247.
Chaque ~"server-pre-process" pourrait générer un `.json` comme le `.vidjil` (mais sans section `clones` ni ...).
Avec en particulier des warnings #2247 et des variables de qualité #2875.Voir #2875 et #2247.
Chaque ~"server-pre-process" pourrait générer un `.json` comme le `.vidjil` (mais sans section `clones` ni ...).
Avec en particulier des warnings #2247 et des variables de qualité #2875.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2945Graphe d'activité du serveur2019-05-06T13:00:42+02:00Mathieu GiraudGraphe d'activité du serveurSuggéré lors d'une réunion à ~"LIL-Lille" : on pourrait avoir un graphe montrant les périodes d'activité / de charge. Public pour le serveur public.Suggéré lors d'une réunion à ~"LIL-Lille" : on pourrait avoir un graphe montrant les périodes d'activité / de charge. Public pour le serveur public.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2936Logguer en db les actions administrateur importantes2017-12-19T20:28:42+01:00Mathieu GiraudLogguer en db les actions administrateur importantesÉvoqué avec @RyanHerb.
Utiliser le mécanisme de log en db (d2188b5) pour stocker en db ce qui concerne la création d'utilisateurs / groupes, les permissions... Sur l'id de l'admin ?Évoqué avec @RyanHerb.
Utiliser le mécanisme de log en db (d2188b5) pour stocker en db ce qui concerne la création d'utilisateurs / groupes, les permissions... Sur l'id de l'admin ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2785Mieux afficher les erreurs serveur et permettre aux utilisateurs de nous cont...2017-11-15T13:50:26+01:00Mathieu GiraudMieux afficher les erreurs serveur et permettre aux utilisateurs de nous contacterCi-dessous quelques exemples de pages 500 ou 502 obtenues récemment. Nous pouvons améliorer nos pages... par exemple, lors d'une 500, une formulation "Something went wrong on our end. Please <a href=...>contact us</a> if the problem pers...Ci-dessous quelques exemples de pages 500 ou 502 obtenues récemment. Nous pouvons améliorer nos pages... par exemple, lors d'une 500, une formulation "Something went wrong on our end. Please <a href=...>contact us</a> if the problem persists", idéalement avec le ticket lié.
Au passage :
- est-ce que nous récupérons bien toutes les erreurs serveur (dans `database.js`) ?
- est-ce que certaines erreurs client devraient avoir le même traitement ?
![gitlab-502](/uploads/810aeb5c17224b40799f00a41d248212/gitlab-502.png)
![ovh-server-error](/uploads/7877f53c16717cd36994bc47649765ec/ovh-server-error.png)
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2723Avoir des tests fonctionnels sur des jeux de démo complet2024-01-17T14:05:34+01:00Mathieu GiraudAvoir des tests fonctionnels sur des jeux de démo completNous devrions rajouter à la suite de tests algo des jeux complets de Démo #2635 vdj#195 avec une visée clinique. Ces tests pourraient être écrits par / validés avec nos utilisateurs. Ils seraient longs à lancer, et constitueraient un sta...Nous devrions rajouter à la suite de tests algo des jeux complets de Démo #2635 vdj#195 avec une visée clinique. Ces tests pourraient être écrits par / validés avec nos utilisateurs. Ils seraient longs à lancer, et constitueraient un stage après les ~"dev-tests-should-get" classiques.
Discuter au passage avec ~"KIE-Kiel" qui fait déjà des "re-certifications" sur nos releases ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2323Tests fonctionnels sur le serveur live pour détecter des incidents de prod2023-03-02T12:03:27+01:00Mathieu GiraudTests fonctionnels sur le serveur live pour détecter des incidents de prodOn en parlait il y a fort longtemps. Et il y a, dans browser/test/Makefile, un `make functional-rbx` (mais qui teste le client).
Plutôt tester des controlleurs (les tests serveur ?) en live.
cc @mikael-s @RyanHerbOn en parlait il y a fort longtemps. Et il y a, dans browser/test/Makefile, un `make functional-rbx` (mais qui teste le client).
Plutôt tester des controlleurs (les tests serveur ?) en live.
cc @mikael-s @RyanHerbThonier FlorianThonier Florian2021-01-18https://gitlab.inria.fr/vidjil/vidjil/-/issues/1587Signature / Geler une analyse2022-05-19T08:03:41+02:00Vidjil TeamSignature / Geler une analyseIl faut pouvoir geler une analyse et marquer dans le rapport qui l'a gelée (ou validée) et quand. Il n'est plus possible de sauvegarder par dessus.
Permet-on de lancer de nouveaux runs sur ce fichier ? De toute façon on garde toujours...Il faut pouvoir geler une analyse et marquer dans le rapport qui l'a gelée (ou validée) et quand. Il n'est plus possible de sauvegarder par dessus.
Permet-on de lancer de nouveaux runs sur ce fichier ? De toute façon on garde toujours les résultats. Mais il faut pouvoir revenir facilement aux résultats sauvegardés.
***
Typiquement, en situation Diag puis MRD, on valide le Diag, et plus tard il y a un nouveau point. On est appelé à re-merger / colorer / .... (On a peut-être le droit de relancer le prog sur le Diag). Mais on a sauvegardé le fichier résultat comme le fichier analysis du Diag.
***
Mis en projet étudiant "tracabalité", sinon en reparler en 2016
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1526Coding practise: Releases régulières, freeze du code, déploiement2020-06-10T08:32:41+02:00Vidjil TeamCoding practise: Releases régulières, freeze du code, déploiementEst-ce que cela vaut le coup de définir un peu mieux notre politique de release, sans tomber dans une usine à gaz ?
Plusieurs projets open-source ont pour politique de faire les grosses modifs *juste après chaque release* … De notre cô...Est-ce que cela vaut le coup de définir un peu mieux notre politique de release, sans tomber dans une usine à gaz ?
Plusieurs projets open-source ont pour politique de faire les grosses modifs *juste après chaque release* … De notre côté, si on fait des releases en début de mois, on pourrait décider d'arriver vers le 15/20 du mois à quelque chose de « stable » au niveau des fonctionnalités d'analyse, et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée.
Et d’ailleurs, est-ce que cela sert de faire tant de releases ? On peut dire oui… si nous en sommes nos premiers utilisateurs : ce serait bien plus stable (et maintenable à long terme) si on reste 1 mois sur la même version sur le serveur. On en est à 7 jours aujourd'hui, on n'a jamais tenu aussi longtemps !
Ce mois de stabilité pourrait devenir une règle, quitte à avoir une config « vidjil-dev » qui lance un autre exécutable Vidjil (et on dirait explicitement aux utilisateurs que c'est une config de test).
***
« et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée. » oui, si c'est associé avec la config vidjil-dev (et qu'on l'utilise vraiment) pour qu'on se rende compte des problèmes dans la version de vidjil.
***
vidjil-dev : pas si évident. Il faudrait que ce soit considéré comme un logiciel à part pour le serveur (pour l'instant on a un chemin vers l'exécutable vidjil).
***
oui, tout à fait. Donc une entrée de plus dans defs.py.
Un jour, nous aurons miTCR, TCRKlass... on doit pouvoir être générique, on commence soft en changeant juste l'exécutable :)
***
Plutôt que d'avoir une autre constante, il vaut mieux un dico des logiciels dispos et de leurs chemins…
***
oui (mais à terme, cela demandera aussi un autre controlleur pour miTCR, pas besoin pour l'instant)
***
« et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée. »
Je suis toujours d'accord avec ça mais on ne le fait pas.
Avoir une branche release_candidate qui chaque mois est remise à jour depuis dev. Seules les corrections de bug sont autorisées sur cette branche et la config vidjil-dev sur le serveur devrait être un vidjil compilé sur cette branche-là. Quand on veut faire une release, on la merge depuis master.
***
ok pour le principe. Sur release-candidate, uniquement des corrections de bug (ce qui veut dire avec test obligé)... mais aussi documentation et tests éventuellement.
Donc trois branches : dev / master / release-candidate ?
Ou peut-on faire avec deux branches seulement : master / release-candidate (on release directement depuis release-candidate) + dev s'il y a des choses qui ne sont pas mûrs pour aller dans master.
***
J'avais ça en tête évidemment : http://nvie.com/posts/a-successful-git-branching-model/
Ça me fait bizarre de penser que les releases ne seraient pas sur master (au moment où on fait la release, il pourrait s'être passé plein de choses sur master qui ne sont pas dans la release, plus les corrections de bugs qui sont communes).
***
Oui, exactement pour le modèle. Cela va changer les habitudes de tous (branche principale = dev).
Planning accéléré pour ce coup-ci : ce soir, release-candidate est branché.
***
release-candidate est branché... il faut tester depuis Jenkins. Est-ce possible sans dupliquer des jobs ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1253Se souvenir des amorces/primers utilisées : comment ?2023-03-28T16:11:50+02:00Vidjil TeamSe souvenir des amorces/primers utilisées : comment ?On pourrait gérer plus proprement les amorces, avec
- des listes d'amorces (Biomed ? nouvelles EC ? d'autres ?)
- en fonction des amorces sélectionnées, les confisg (ou les stats) sont différents, ou d'autres features
- et certains...On pourrait gérer plus proprement les amorces, avec
- des listes d'amorces (Biomed ? nouvelles EC ? d'autres ?)
- en fonction des amorces sélectionnées, les confisg (ou les stats) sont différents, ou d'autres features
- et certains réglages permettraient de chosir directement un "kit" d'amorces
Ce n'est pas facile, que cela soit au niveau de la db, du browser derrière, et même de la conception / de ce qu'on veut. Vraiment pas la priorité pour l'instant.
***
mis dans la demande d'ADT, 2016Web 2023.10