1) Parallel steps are the common workflow case
2) Build logs for parallel steps are not informative
3) A user would expect Stage View to somehow address the issue
- stage declarations within parallel sections are not being considered as parallel
- steps within one parallelized step are being mixed => no info in the view (see the screenshot)
Test script (move stage declarations where you want):
comment from JGlick:
So concretely: the stage view would, for a given build (row), continue to display a linear sequence of stages (columns) with their associated times and so on; but each cell (stage of a build) would be some rendering of an st-planar graph, with structure determined according to the presence of steps of interest like parallel or a proposed label. Sort of like the existing Workflow Steps, but rendered as a graph rather than a tree table, restricted to displaying certain steps, and divided by stage.
A simpler request would be to only display branches of one top-level parallel step, if any. (I.e., an st-planar graph which is either trivial—one vertex—or where all vertices other than the source and sink are directly connected to both the source and the sink.) This more limited UI would match that of the Build Pipeline plugin.
Note that there is also a request
JENKINS-29892 which would allow several stages to share concurrency semantics, but I think that need not have any effect on visualization; it would just be an internal change in the stage step.