action #70633
open
Add option to keep unchanged jobs when rescheduling a product
Added by favogt over 3 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
User story¶
As a test author and admin, I want to hook up test suites and see whether they work immediately.
Currently, after editing test suites, medium types or job groups, the whole product has to be rescheduled to make the changes effective,
which effectively restarts all tests, which is a waste of time. For instance, when adding a new test to the Development TW group,
rescheduling the product would also retest everything in the main TW group.
It would be useful to have an option which avoids creating new jobs if the previous one has idential settings, or somehow limit it in
some other way.
Acceptance criteria¶
- When creating a new test suite and adding it to a job group, a reschedule of the product would then only create jobs for
for the new test suite, for instance. A reschedule after editing a test suite would only affect jobs with that test suite.
- Category set to Feature requests
- Priority changed from Normal to Low
- Target version set to future
The tricky thing is that we have multiple and many sources for test settings. So it is rather hard for the user to communicate to openQA which settings should be re-evaluated and which ones not. Also think about the extreme cases like settings in the worker machine's /etc/openqa/workers.ini that will be only re-evaluated if jobs are actually started on the worker. This is something that the web UI, knowning all settings from test suites, etc., can not know. So far by default we use the conservative and save approach to require a complete reschedule of a product. Of course you are only asking for an "option" but this always introduces further complexity, potential for regressions, breakage as well as confusion on the side of users. Hence I would regard this request with great care.
It would help if you use the ticket template from https://progress.opensuse.org/projects/openqav3/wiki#Feature-requests and also fill a user story or use case or motivation so that we can better understand what the goal is that you want to reach. I guess here you are aiming for the compromise of save testing time invested by a little bit more complexity in understanding the scheduling process, right?
- Description updated (diff)
The tricky thing is that we have multiple and many sources for test settings. So it is rather hard for the user to communicate to openQA which settings should be re-evaluated and which ones not. Also think about the extreme cases like settings in the worker machine's /etc/openqa/workers.ini that will be only re-evaluated if jobs are actually started on the worker. This is something that the web UI, knowning all settings from test suites, etc., can not know. So far by default we use the conservative and save approach to require a complete reschedule of a product. Of course you are only asking for an "option" but this always introduces further complexity, potential for regressions, breakage as well as confusion on the side of users. Hence I would regard this request with great care.
It's not possible to perform magic, so I'm not asking for that. I'm specifically asking for an option useful after job group or test suite changes, so anything outside of the web UI shouldn't matter.
It would help if you use the ticket template from https://progress.opensuse.org/projects/openqav3/wiki#Feature-requests and also fill a user story or use case or motivation so that we can better understand what the goal is that you want to reach. I guess here you are aiming for the compromise of save testing time invested by a little bit more complexity in understanding the scheduling process, right?
Not quite, I updated the description.
Also available in: Atom
PDF