QA » openQA Project

It would have also been great to give a concrete example. At least I am not quite sure how this is supposed to work in detail.

Example:
Here we have a scheduled product which generated 238 jobs across multiple job groups: https://openqa.suse.de/admin/productlog?id=1740102
And from that scheduled product, I want to retrigger (automatically reload any testsuite/medium/job group changes) just this job and its 13 children: https://openqa.suse.de/tests/10596043

I keep it as support ticket. If AC1 is clarified, we should estimate it.

How do you want to select the relevant subset of jobs?

I suppose you could specify the target jobs via TEST=… as you already can right now (the variable supports a comma-separated list). To take children of those jobs into account as well you'd also specify _INCLUDE_CHILDREN=1 which would be a new setting. It would include all kinds of children (chained, parallel, directly chained) and recursively cover all children. Is that good enough or do you need to select by dependency type and limit the depth?

I'm not sure how hard/easy that would be to implement right now and I'm also wondering how hard/easy it would be after https://github.com/os-autoinst/openQA/pull/4999 has been merged.

An additional usability issue would be that we currently only allow to re-trigger a scheduled product with the same settings as before. So you'd have to manually craft a new isos post command. Is that acceptable?

mkittler wrote:

This leads to the question: How do you want to select the relevant subset of jobs?

Just like in the example I gave above, I'll typically want to retrigger a specific job and its dependency subtree. So I want to select by single job ID. Ideally, the retrigger option would also be included in the web UI in the "restart job" drop-down menu.

I don't care whether the full retriggered job list will be the original one or the new one from job group config. But any individual job settings changes in the job group config must be applied to the corresponding retriggered jobs.

So I want to select by single job ID.

Ok, by job ID. That means the code which is scheduling a product needed to map newly generated jobs to an existing job ID. Wouldn't it be more reliable to just specify the TEST name?

Ideally, the retrigger option would also be included in the web UI in the "restart job" drop-down menu.

I suppose that would be nice. It would be "Re-trigger scheduled product from here including child jobs". Since this is not a "restart" in the usual sense it may deserve a distinct icon/button - especially also since this way of re-triggering is also allowed if the job has already been restarted in the usual sense.

I don't care whether the full retriggered job list will be the original one or the new one from job group config.

Then I'd make it the new one because that will be way easier to implement. (After all we'd just run a filtered version of the code for scheduling an ISO again.)

But any individual job settings changes in the job group config must be applied to the corresponding retriggered jobs.

Yes. I suppose that's the point of the whole feature. By the way, what do we do if the amended settings would not lead to this job being created anymore at all? I suppose then you're just supposed to get a message stating that.

I'm not sure how hard/easy that would be to implement right now …

Judging by the code we currently pull parents into the set of jobs to be triggered. So this feature would "just" be the reverse. I'll have to experiment myself to see whether this is actually how it behaves (because I might misunderstand the code). If it was true, then it might be easy to implement. It would also mean that https://github.com/os-autoinst/openQA/pull/4999 is not in the way (as the current implementation already de-duplicates this kind of dependency handling).

mkittler wrote:

Ok, by job ID. That means the code which is scheduling a product needed to map newly generated jobs to an existing job ID. Wouldn't it be more reliable to just specify the TEST name?

It'd be less convenient for the user to not allow job ID. If you need to match internally by TEST name, you can simply load it from the existing job.

Yes. I suppose that's the point of the whole feature. By the way, what do we do if the amended settings would not lead to this job being created anymore at all? I suppose then you're just supposed to get a message stating that.

If the whole dependency subtree including the target job got removed, then there's nothing to retrigger if you strictly follow the new job group config. You could still opttionally force-retrigger the target job itself with empty settings from the job group (so only testsuite and medium setting will apply).

Ok. Since this touches the same code as https://github.com/os-autoinst/openQA/pull/4999 (merged) I'd like to have this PR merged first. I'll give it a try when I have time although of course other issues have priority.

I'll typically want to retrigger a specific job and its dependency subtree.

Looks like there's the existing scheduling variable _SKIP_CHAINED_DEPS that does exactly that. Except that it only affects chained and directly chained dependencies. You'd still get parallel parents. However, that's supposedly even what you actually want (because only re-triggering the parallel child without its parent is likely useless).

However, besides adding UI for using _SKIP_CHAINED_DEPS more conveniently, there's still something missing. When we would specify the "starting point" via the TEST variable we'd actually only get that job and no children. So we need a mechanism to pull in children automatically in the same way we currently pull in parents automatically (unless _SKIP_CHAINED_DEPS is specified).

mkittler wrote:

I've been updating https://github.com/os-autoinst/openQA/pull/5096. I'm waiting for feedback before continuing.

Merged!

Yes, so what's left is the UI.

I suppose I'll add a context menu to the dependency tree with the menu item "Re-schedule product from here". Addition an additional button on every node in the tree would likely take too much space and clutter the graph too much. Maybe a changed mouse cursor could indicate the presence of the context menu.

I'm not sure whether restarting a scheduled product with additional/updated settings has been implemented yet so possibly that needed to be implemented as well.

mkittler wrote:

Yes, so what's left is the UI.

I suppose I'll add a context menu to the dependency tree with the menu item "Re-schedule product from here". Addition an additional button on every node in the tree would likely take too much space and clutter the graph too much. Maybe a changed mouse cursor could indicate the presence of the context menu.

I think the "restart job" drop down menu in the job result box would be a better place than the dependency graph.

Ok, and I suppose this would also be easier to implement anyways. I've just though of the dependency graph because then it doesn't matter on which job one currently is but I suppose one can simply navigate to the "start" job and restart from there.

PR: https://github.com/os-autoinst/openQA/pull/5233

I ended up adding another button in the "Scheduled product: …" line. Adding this in the drop down menu of the restart button would be problematic because we hide the restart button if restarting is not possible but it wouldn't make sense to disallow the partial retrigger in all such cases.

mkittler wrote:

PR: https://github.com/os-autoinst/openQA/pull/5233

I ended up adding another button in the "Scheduled product: …" line. Adding this in the drop down menu of the restart button would be problematic because we hide the restart button if restarting is not possible but it wouldn't make sense to disallow the partial retrigger in all such cases.

Merged.

https://build.opensuse.org/package/live_build_log/devel:openQA/openQA/openSUSE_Leap_15.4/x86_64

unterminated quoted string literal at /usr/lib/perl5/vendor_perl/5.26.1/Mojolicious/Plugin/AssetPack/Pipe/JavaScript.pm line 22.

This seems to be a bug fixed in Javascript::Minifier::XS as it happens with version 0.14, but not 0.15
Changes here https://metacpan.org/dist/JavaScript-Minifier-XS seem unrelated though.

https://github.com/os-autoinst/openQA/pull/5264 Use regular single quotes in javascript code (merged)

Thanks for taking care. I guess now we can wait a little bit longer for user feedback.