QA » openQA Project

To illustrate the problem:
https://openqa.suse.de/tests/2033801#settings has one parent and one child - but the parent has actually 8 children, so we talk at least about 9 jobs to be considered. If just one of them has a chained dependency, you won't be able to detect the reason it stays in scheduled within reasonable time.

http://visjs.org/showcase/index.html looks promising

What about d3? http://emptypipes.org/2017/04/29/d3v4-selectable-zoomable-force-directed-graph/

https://github.com/d3/d3/wiki/Gallery

Not a new idea actually.

When implementing this, we should keep in mind that we might want this graph on multiple pages: https://progress.opensuse.org/issues/15850, https://progress.opensuse.org/issues/18402

Additionally, I suppose those tickets should be postponed until we implement displaying the dependencies properly.

D3 looks good. And it wouldn't be hard to use considering the examples. However, how should a job be represented in the graph? I mean a graph of dots looks cool, but it is still kind of useless without knowing which point corresponds to which job. So likely the label placement example fits best here. I've just played around with it and it should be possible to customize it, eg. adding a tool-tip would be quite simple.

I find this a lot of code compared to http://visjs.org/examples/network/edgeStyles/arrows.html

I personally find the other places good enough - the icons used make it clear that it's part of a cluster. And if I want to know the details, I can go to any of the jobs within the cluster and get a full picture of the cluster within its details. So to me this is clearly a tab within tests/X

Thanks for this change, it looks much better now.

Will it be possible to see parent/children relation also on dependencies tab?
It's quite important info for test writers - mostly when using mutexes.

Currently PARALLEL_WITH groups cluster jobs in single "blue box", we lost parent/children info that was on settings tab.
CaaSP for example: https://openqa.suse.de/tests/1760064#dependencies

the parent is on top, no?

the parent is on top, no?

Not necessarily. That information is lost indeed. Each job which belongs to a cluster only has a cluster ID but no special role within the cluster anymore.

@mkravec Which job the parent is and which job the child is doesn't make a difference for PARALLEL_WITH dependencies. You get the same behavior if you switch those roles. Hence I thought it wouldn't be a problem to loose that information. I could add the information to the tooltip if that's required.

@mkittler it matters from test writer POV, for example:

• running job - when parent dies, all children die - we need to handle log export from child jobs in case of parent failure
• lockapi - if mutex owner is a child job then job_id has to be used - mutex_lock($name, $owner_id)
• clone_job - only cloning child jobs work - because it clones parent automatically

good example for demo (3 chain levels, 2 cluster): https://openqa.suse.de/tests/2196682#dependencies

@mkravec Added the information to the tool-tip: https://github.com/os-autoinst/openQA/pull/1840 Seems like GitHub wasn't actually able to create that PR. I'll try it again when GitHub has fixed their issues.

@mkittler thank you