Show dependency graph also for cloned/restarted jobs #4507
Conversation
Martchus
force-pushed
the
dependency-graph
branch
from
197e7a7
to
ec8f81b
Compare
Martchus
force-pushed
the
dependency-graph
branch
from
ec8f81b
to
74b0079
Compare
|
Just a few examples how it looks like. All graphs (except the last example) are real examples from our production instance. A fully restarted dependency tree looks definitively as it should. Partially restarted trees also look good most of the time. Btw, these are directly chained dependencies (and therefore the "parent chain" has been restarted and not only the child). However, partially restarted trees can also look like this: In this case restarted children of another "root" job are dragged into the graph. So far I haven't found a good solution to avoid this (without impairing other cases). However, I don't consider it that bad. None of the parallel clusters is only shown half and it wouldn't drag any further chained children of the wrong "restart depth" into the graph. The graph of the latest jobs is also not affected at all (so there's no regression): By the way, a partial restart plus another partial restart as described in #4498 (comment) looks like this: The initial cluster is rendered exactly like one would expect it: This is the graph for the first clone of root1 (after root1 has been restarted without #4498 and root2 has been restarted separately in addition and then root1 has been restarted again with #4498): It looks a bit confusing but also shows the problem I was getting at in the other PR quite nicely (that child1 has been restarted twice). So I guess having it rendered this way isn't the worst. The graph for the latest jobs looks still simple (so again, no regression): Maybe I can still tweak it further to simplify graphs of restarted jobs. However, considering those graphs weren't displayed before at all and graphs for the latest jobs are still as before I already consider this an improvement. Of course I still need to adapt tests but I wanted to wait for feedback first. |
Simple changes split out of #4507
|
The example about "A fully restarted dependency" shows that in one case the "ppc64le-hmc-4disk" is coming first, and the other time at end. Can this be influenced by ordering before the data is rendered or is it really something non-predictable by the graphics rendering? The part about "In this case restarted children of another "root" job are dragged into the graph" is a bit worrying and I don't really understand it but I would accept it for now. Rest looks fine. |
|
About the first question: This is indeed inconsistent but unrelated to this change. The order in which nodes are added to the tree depends on the current job and I selected a different job in these screenshots. I suppose we could simply sort the nodes in the end, possibly even in JavaScript. One thing I've forgotten to mention: The code should ensure that no nodes are added to the tree which are not somehow connected to other nodes. So all jobs being dragged into the graph should at least indirectly depend on the current job. (That's what the |
Martchus
force-pushed
the
dependency-graph
branch
2 times, most recently
from
f1bf0d3
to
04630f5
Compare
Codecov Report
@@ Coverage Diff @@
## master #4507 +/- ##
=======================================
Coverage 97.96% 97.97%
=======================================
Files 374 374
Lines 34063 34108 +45
=======================================
+ Hits 33371 33416 +45
Misses 692 692
Continue to review full report at Codecov.
|
So far the order of elements within the dependency tree could be different depending on the current job. This change makes it consistent by sorting the edges before passing them to the rendering library. (Sorting nodes does not help and also does not seem to be required.) See os-autoinst#4507 (comment)
So far the order of elements within the dependency tree could be different depending on the current job. This change makes it consistent by sorting the edges before passing them to the rendering library. (Sorting nodes does not help and also does not seem to be required.) See os-autoinst#4507 (comment)
I suppose it makes sense to *not* switch tabs when clicking on a node within the dependencies tab.
* Do not blindly follow the clone chain to the latest job anymore
* Display always the current job, even if it is not the latest clone
* Avoid following the clone chain to the latest job for children if
the child's clone is not a dependency of the parent job anymore
* Avoid following the clone chain to the latest job for parents
* Do not display (directly) chained children of jobs when the clone depth
does not match the one from the current job to avoid dragging too many
jobs into the tree
* See https://progress.opensuse.org/issues/69976
If a child hasn't been restarted as often as its parent it still makes sense to show that child in the restarted parent's dependency tree like it was the case before 87f9c47 (as tested by `t/ui/16-tests_dependencies.t`).
Martchus
force-pushed
the
dependency-graph
branch
from
04630f5
to
5c496bc
Compare
So far the order of elements within the dependency tree could be different depending on the current job. This change makes it consistent by sorting the edges before passing them to the rendering library. (Sorting nodes does not help and also does not seem to be required.) See os-autoinst#4507 (comment)
the child's clone is not a dependency of the parent job anymore
does not match the one from the current job to avoid dragging too many
jobs into the tree