Parallel branch times are wrong (time of longest branch)

[timbrown5]

The only minor issue I see left is that the parallel branch A seems to inherit the timing info from branch B when B finally completes. Branch A should take roughly 15s because it contains a sleep 15 step, while Branch B should take roughly 30s because it contains a sleep 30 step. The timing info of all the stages within both branches is correct.

I appreciate all of your hard work on these issues! The console view is amazing now 👍

Originally posted by @stuartrowe in #362 (comment)

[sparrowt]

Yes this was broken in blue ocean too - it would be lovely to get this right otherwise it's very difficult to analyse which parallel branch takes the longest after the fact because they all show the same time.

[felipecrs]

I'm not sure if it's the same issue or not, but I think it is:

Sorry for the poor screenshot, but it's basically saying that every parallel stage took 37 minutes, while in fact each one took its own unique time and 37 minutes was the longest one.

[stuartrowe]

That's the same issue. I was just looking into this earlier today.

One of the earlier comments suggests that this was an issue in Blue Ocean as well, which means that pipeline-graph-analysis-plugin's StatusAndTiming#computeParallelBranchTimings method could be part of the problem.

Although I noticed that while the pipeline is running the branch timings are individually correct - it's when the pipeline completes that all branches assume the overall timing. That observation makes this code suspicious as well given the comment about expecting the endNode to be null when the pipeline is running: ParallelBlockRelationship#calculateTimings.

[felipecrs]

Although I noticed that while the pipeline is running the branch timings are individually correct

I can confirm that btw.

[stuartrowe]

Here's the issue:

When the run is building the timing of the parallel branch is correctly computed using the start time of the branch end node - the start time of the branch start node: https://github.com/jenkinsci/pipeline-graph-analysis-plugin/blob/baa36bf248c2b42f17a580c6590ff5280a34525a/src/main/java/org/jenkinsci/plugins/workflow/pipelinegraphanalysis/StatusAndTiming.java#L379-L386

Otherwise the timing is computed using the start time of the "after" node which for a parallel branch is the closing node for the actual parallel step. This is why the branches all end up with the same timing once the run completes:
https://github.com/jenkinsci/pipeline-graph-analysis-plugin/blob/baa36bf248c2b42f17a580c6590ff5280a34525a/src/main/java/org/jenkinsci/plugins/workflow/pipelinegraphanalysis/StatusAndTiming.java#L375

I'm not familiar enough with how this plugin is used, but the conditions around using the end node for timing don't seem necessary to me. I'll try removing locally and running tests.

[stuartrowe]

jenkinsci/pipeline-graph-analysis-plugin#164

[stuartrowe]

Resolved by pipeline-graph-analysis-plugin v237.v2b_75640ca_888