# Reducing wait time of testing request
**URL:** https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364
**Category:** Dashboards
**Created:** [August 6, 2019, 8:04am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364 "2019-08-06T08:04:46Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@Michael](https://discourse.paraview.org/u/Michael)
#### Post date: [August 6, 2019, 8:04am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/1 "2019-08-06T08:04:46Z")
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?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 6, 2019, 8:09am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/2 "2019-08-06T08:09:09Z")
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
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 6, 2019, 11:49am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/3 "2019-08-06T11:49:45Z")
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 6, 2019, 1:17pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/4 "2019-08-06T13:17:18Z")
> do `Do: test --merged` to avoid running tests on too old a branch
Should this be default ?
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [August 7, 2019, 1:02am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/5 "2019-08-07T01:02:17Z")
`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.
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 17, 2019, 12:11pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/6 "2019-08-17T12:11:51Z")
> [@mwestphal](#):
>
> Should this be default ?
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 20, 2019, 4:28pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/7 "2019-08-20T16:28:19Z")
nemesis as an 8hour delay currently.
It can’t handle two build of ParaView imo.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [August 20, 2019, 7:42pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/8 "2019-08-20T19:42:24Z")
> upgrading hardware of the slowest buildbots
The replacement for `nemesis` is sitting in an office here waiting to be made available (another project is using it as a Windows box). I’ll probably get around to swapping them when Windows 10 makes its sweep across the machines.
> add an option to run only some tests based on regex (generally sufficient for WIP MR)
A WIP commit to comment out unrelated tests can help here. Just remember to remove it before merging (adding `WIP` as a prefix to the commit allows the robot to enforce this remembering for you).
> run only tests impacted by the modifications (seems difficult to implement though)
Indeed. I’ve thought about this, but haven’t come up with a good way of doing it. In ParaView’s case, all the XML tests end up getting affected since `paraview` the executable ends up depending on “everything”.
> add an option to set the priority of the request
Without a central priority queue, this is just going to be abused.
Note that I’d really like to migrate to GitLab-CI at some point and allow more hardware to share a given build configuration, but that is probably at least a year down the line at this point for VTK/ParaView.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 21, 2019, 7:04am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/9 "2019-08-21T07:04:54Z")
> [@ben.boeckel](#):
>
> > upgrading hardware of the slowest buildbots
>
> The replacement for `nemesis` is sitting in an office here waiting to be made available (another project is using it as a Windows box). I’ll probably get around to swapping them when Windows 10 makes its sweep across the machines.
Great !
> [@](#):
>
> > add an option to run only some tests based on regex (generally sufficient for WIP MR)
>
> A WIP commit to comment out unrelated tests can help here. Just remember to remove it before merging (adding `WIP` as a prefix to the commit allows the robot to enforce this remembering for you).
That’s actually quite smart ! I should have thought of that.
It is not that easy to do though, as you need to modify different part of multiple CMakeLists.txt, unless I’m missing something.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [August 21, 2019, 11:50am UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/10 "2019-08-21T11:50:10Z")
How easy it is depends on how long you’re willing to wait for results for your test(s). Though that is also a function of others doing the same to reduce their test load…
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [May 21, 2020, 2:43pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/11 "2020-05-21T14:43:17Z")
One thing I’m doing right now that may be helpful to faster overall dashboard turnaround time is to run an initial round of tests on a faster machine, such as `taanab`, and fixing any warnings/errors it turns up before running the tests on all dashboard machines.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 21, 2020, 5:21pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/12 "2020-05-21T17:21:10Z")
> [@cory.quammen](#):
>
> on a faster machine
Note that `taanab` is mostly faster because its build setups are just _much_ smaller than any other machine’s builds.
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [May 21, 2020, 5:25pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/13 "2020-05-21T17:25:05Z")
I have an MR up to increase the branch stable timer for master and release branch so that the master builds are not prioritized over MRs too quickly. that should help with turn around time during work hours
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [May 21, 2020, 5:25pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/14 "2020-05-21T17:25:42Z")
> [@ben.boeckel](#):
>
> Note that `taanab` is mostly faster because its build setups are just _much_ smaller than any other machine’s builds.
That’s fine - it’s still useful initial feedback for building errors and warnings before committing the slower builders to a chunk of work.
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [May 21, 2020, 5:26pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/15 "2020-05-21T17:26:55Z")
> [@utkarsh.ayachit](#):
>
> I have an MR up to increase the branch stable timer for master and release branch so that the master builds are not prioritized over MRs too quickly. that should with turn around time during work hours
What would be great is if `master` and `release` branches could be killed if there is an MR waiting. I have no idea how to implement that or if it is possible.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 21, 2020, 6:14pm UTC](https://discourse.paraview.org/t/reducing-wait-time-of-testing-request/2364/16 "2020-05-21T18:14:11Z")
> [@cory.quammen](#):
>
> What would be great is if `master` and `release` branches could be killed if there is an MR waiting. I have no idea how to implement that or if it is possible.
There are remnants of me trying to get `Do: test --stop` to stop an MR build that has already started, but that never got anywhere. The “Stop build” button on the web interface is “in there” and not easily triggerable from other code.