QA » openQA Project

Hi Marius,

Happy to see progress for this ticket. Each improvement from openQA side about the directly chained tests will benefit us. We are even in discussion if we should postpone our test reconstruction until directly chain gets more mature.

Here are the test chains we created FYI: https://openqa.nue.suse.com/tests/overview?distri=sle&version=15-SP2&build=207.1&groupid=213

Some questions about this ticket:

What does 'clone' here mean? If I restart tests in a directly chain on web UI, are these restarted tests called cloned jobs here? or those jobs which are restarted via openqa-clone-job?

If we only rerun part of tests(a sub tree of the original test chain tree), will the 'cloning tree' graph be the sub tree only? Can we still view or operate the original tree after implementing this ticket?

The graph is not just a graph, it is the actual chain, we can rerun jobs with the graph, do I get it correctly?

What does 'clone' here mean? If I restart tests in a directly chain on web UI, are these restarted tests called cloned jobs here?

Yes. Jobs which have been restarted via the web UI or direct use of the REST-API's restart and duplicate routes are considered "cloned" and the newly created jobs "clones". That's true for the context of this issue and the web UI uses the same terms in several error messages and the "Cloned as …"/"Clone of …" info.

or those jobs which are restarted via openqa-clone-job?

No. Jobs "restarted" via that script are actually not considered restarted/cloned within the context of this issue and also not by the web UI, e.g. the web UI would not show the "Cloned as …"/"Clone of …" info. Note that the openqa-clone-job does not support parallel and directly chained dependencies so it is not really helpful here anyways.

If we only rerun part of tests(a sub tree of the original test chain tree), will the 'cloning tree' graph be the sub tree only?

I'm not 100 % sure what you mean but this question likely falls under the points I've mentioned under "notes" within the ticket description. That means it isn't completely sorted out at this point.

Can we still view or operate the original tree after implementing this ticket?

I don't know what you mean with operate. Being able to view the original tree is the main point of this issue.

The graph is not just a graph, it is the actual chain, we can rerun jobs with the graph, do I get it correctly?

The graph is just a graph. It shows dependencies between jobs. It does not show the cloning/restarting chain. Showing the graph for jobs which have already been cloned does not mean you can restart these jobs now.

Hi Marius, I think I get the meaning. Taking a ABCDE test chain as an example, currently, given we restart a sub chain, such as ABC, then only ABC are shown in the new created graph, DE are lost, DE are only showed up in the original graph. After implementing this ticket, in the same case, DE will be shown in the new graph as well even if they have not been restarted. The new graph is identical with the original one, ABCDE. But on the new graph, only ABC which have been restarted are allowed to be restarted again, DE are not allowed. Do I follow you exactly?

If yes, it helps in some extend. The test reviewers always see the correct test dependencies regardless any restarting.

Of course, what we are expected most is DE can be restarted in the new graph(or in the original graph, or in any other ways) as well.

Please understand that this ticket is prioritized with low prio and we keep it in the "future" target version, i.e. the SUSE QA tools team does not plan to implement this anytime soon (not within the next months or years). Given that the ticket has already received good and comprehensive explanations and implmentation suggestions it can be feasible for any outside contributor to implement. We are always happy to receive pull requests from anyone :)

Stumbled over this while investigating #102428. Had quite a few parallel_failed jobs where the actual fail reason was hard to track down because of the missing dependency links. So consider this a +1 for the feature. :)

Maybe it makes sense to do this before working on further tickets of the epic. I know, it is only a graphical improvement but seeing the dependency tree also of cloned jobs would be helpful e.g. to debug problems when making changes for #95783.

merged and deployed (on osd). I checked one job and the dependency graph in that example looks the same as in before so good. Also in clonee jobs I can see the dependency graph so all looks good now. Please crosscheck both ACs in production once again and then feel free to resolve.