action #69976
Updated by okurz over 2 years ago
## User ### user story * As a tester or openQA developer I, I often follow links to openQA jobs (e.g. from a ticket) and for further investigation it would be useful to see the dependency tree - even though the job has already been cloned in the meantime. * As a new user of openQA, I would like to avoid getting the wrong impression that dependencies of a job could not be created or have been deleted although they are just not displayed. ## Acceptance ### acceptance criteria * **AC1:** AC0: The "Dependencies" tab is shown for jobs which have been cloned/restarted. * **AC2:** AC1: The tab shown as in `AC0` contains the actual job one is looking at (and *not* a different job in the "cloning chain"). ## Notes ### notes Here a few points for consideration. I wouldn't call these ACs because it requires some experimentation to find out what works best in practice and can be implemented with reasonable effort. I only added these points because I'm already aware of certain cases which can be tricky (and have been tricky in the past) and should be thought through when implementing this issue. 1. The dependency graph has been disabled on purpose so far: Showing not only all children but also all of their clones lead to overwhelmingly big graphs which we should keep avoiding. So far we avoid the problem by showing only the latest jobs of the "cloning chain" within the graph but that means cloned jobs have no graph at all. 2. It would likely be useful to show graphs of old jobs as well. Users frequently get confused about missing graphs and sometimes use older jobs as reference. 1. Only dependencies of the same "cloning level" should be shown within a graph to avoid the problem described in `1.`. 2. A dependency cluster might have only been cloned partially. Consider the example of restarting only a child but not the parent. Than there is not "one" cloning level. To avoid the problem described in `1.` the graph of the parent job in this example should likely only show the most recent child like it does right now. The graph of the original child jobs should contain only the original child job. The graph of the cloned child jobs should contain only the cloned child job. 2.1. The last two statements are obvious but so far the graph of the original child job would not show the original child job at all but only contain the cloned child job. 3. When skipping the restart of a passed/softaild child, the child is so far nevertheless added as child of to the cloned parent and therefore ends up as part of the old and the new cluster. So not only a parent (as explained in `2.2`) but also a child might be part of multiple cloning levels. The graph rendering should treat both cases sensibly. To be consistent with `2.2` we should only show the most recent parent in the graph of the skipped child. ## Suggestions ### suggestions 1. Try to understand the code in `OpenQA::WebAPI::Controller::Test::dependencies` and related functions. Reading the code of the JavaScript function `renderDependencyGraph` might be helpful as well. It should not be necessary to touch any other code because this is only about *displaying* dependencies. 2. Change the condition `!defined($job->clone_id) && $job->has_dependencies` to `$job->has_dependencies`. That's all what's needed to implement AC0. 3. Create some relevant job clusters to test AC1 and the scenarios mentioned under notes. One could either start testing manually (e.g. by using manual SQL statements to add the required dependencies) or by extending some of the dependencies tests. 4. Play around with the code mentioned in `1.` to implement AC1 considering the notes.