Is this issue associated with pull request https://github.com/Diabol/delivery-pipeline-plugin/pull/58/ ? Could you attach a screenshot of the proposed view?

In which use cases is the total pipeline build time interesting? There is currently work on allowing manual triggers in pipelines (see JENKINS-21009), so a concern is how this would affect the total build time calculation.

Screenshots are attached.

For our project we have requirements on total build time of each pipeline, from unit tests all the way to production. This feature will make the total build time very easy to read.

In my opinion manual triggers do not make too much sense because pipelines should be automatic and autonomous. If one stage or task in the pipeline fails for some reason, it's better to start a new pipeline build, (e.g. fixing test failures, committing new code which kicks off the pipeline), not resume from where it fails.

That being said, when the pipeline is restarted manually, new build time will be used for calculation.

Thank you for the screenshots associated with the pull request.

I would prefer to display the actual time for the pipeline to finish, rather than just adding up the build task duration for each task. In a pipeline with parallel stages the figure would otherwise be deceptive.

Thanks for the comment. I think you are right about the concurrent builds. I will update the code.

We (the authors of the plugin, i.e. Diabol), believe that manual triggers DO make sense in a pipeline. A high degree of automation is great and necessary in a pipeline, but some decisions will be taken by humans in many pipelines. What should always be automated is the repetitive tasks. This is one of the reasons that we believe that the total CYCLE time is an important measure.

Also, I think your presentation is focusing too much on 'anecdotal' measurements. It's the statistical values that should matter. I attach a suggestion for displaying total cycle time and total build time. For the aggregate row, it's the same but with statistical values: average, minimum, median, 90-percentile and maximum. How about that?

Pipeline with individual cycle and build times and stats.

Great suggestion. I will work more on that. Meanwhile I'm going to close the PR and lower the priority of this JIRA.