Reducing wait time of testing request

Particularly for ParaView, job queue is very long on some buildbots (10+ hours) and seems related more to testing than configuring/building.
It can be frustrating to be able to run tests only once a day when deadlines are very short.

Here are some ideas:

  • upgrading hardware of the slowest buildbots
  • add an option to run only some tests based on regex (generally sufficient for WIP MR)
  • run only tests impacted by the modifications (seems difficult to implement though)
  • add an option to set the priority of the request

What do you think?

A few other ideas :

  • Rework test that are more than 20s long to improve timings
  • Add an option to run only pv, pvcs or pvcrs tests
  • Improve connection time for pvcs and pvcrs tests
  • Reduce default timeout of 180s to 60s
  • Add an option for only building, not testing

Folks can also get a little smart about testing.

  • if fixing doc, no need to run tests
  • if fixing a warning or smaller fixes, just use -i to limit to a builder or two
  • try to update to latest master before requesting tests or do Do: test --merged to avoid running tests on too old a branch
  • when adding a new test, try to see if it’s easier to combine the test in an existing test rather than adding a whole new one.

we do need to update/replace nemesis. it has too many builders right now.

do Do: test --merged to avoid running tests on too old a branch

Should this be default ?

dres had an issue with a macOS dialog appearing after ParaView crashed that prevented additional instances from running, hence tests were essentially blocked. I prevented these dialogs from appearing (hopefully) by applying the command

defaults write org.paraview.ParaView NSQuitAlwaysKeepsWindows -bool false

dres seems to be chugging along faster now as a result.

I am not sure. I’d much rather people rebased their topics to latest master before running tests manually. I prefer things to be explicit, but that’s just my preference.

1 Like