Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • vidjil vidjil
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,698
    • Issues 1,698
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 91
    • Merge requests 91
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • vidjil
  • vidjilvidjil
  • Issues
  • #1620

Closed
Open
Created Nov 29, 2016 by Vidjil Team@vidjilteamMaintainer

Vidjil-all-slaves directement après coverage ?

Vidjil-coverage dure 4 min valgrind-unit dure > 20 min

On doit donc souvent attendre ~ 25 minutes avant d'avoir des bugs (ou des résolutions) dans all-slaves. Ne faudrait-il pas lancer all-slaves directement après coverage (quitte à supprimer valgrind-unit, puisque valgrind est inclus dans all-slaves) ?


Vidjil-coverage lance déjà les tests. Ils passent sur meccano alors qu'ils ne passent pas sur all slaves, c'est pas de chance. Mais le rôle de valgrind-unit est de faire une première passe de valgrind sur les tests unitaires pour voir s'il n'y a pas de problème dessus avant de lancer ces tests unitaires avec valgrind sur tous les slaves (pour éviter d'avoir tous les slaves qui râlent en même temps, c'est même toi qui l'avait demandé).

Dans ce cas les tests semblent passer sous debian (c'est pour ça que ça franchit successivement coverage et valgrind-unit sans souci) mais foire sur le all-slaves.

Supprimer valgrind-unit n'améliorerait pas la situation actuelle mais obligerait à lancer les tests sur tous les slaves même quand il y a un problème basique impactant tous les slaves. Ici le problème n'impacte pas tous les slaves, donc on ne voit pas l'intérêt de valgrind-unit…


ok. Effectivement, la dépendance unit > all-slaves-unit est justifée.

Pour boucler la boucle, on pourrait avoir: coverage (meccano) 4' > all-slaves (sans unit) 4' > unit 20' > all-slaves (avec unit) 20 '

mais cela en fait un de plus...


@mikael-s

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking