Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22482

Display pipeline total build time

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      It would be a nice feature to display total build time of each pipeline in the title.

        Attachments

          Activity

          Hide
          tommysdk Tommy Tynjä added a comment -

          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.

          Show
          tommysdk Tommy Tynjä added a comment - 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.
          Hide
          zihaoyuhbo Zihao Yu added a comment - - edited

          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.

          Show
          zihaoyuhbo Zihao Yu added a comment - - edited 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.
          Hide
          tommysdk Tommy Tynjä added a comment -

          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.

          Show
          tommysdk Tommy Tynjä added a comment - 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.
          Hide
          zihaoyuhbo Zihao Yu added a comment -

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

          Show
          zihaoyuhbo Zihao Yu added a comment - Thanks for the comment. I think you are right about the concurrent builds. I will update the code.
          Hide
          marcus_phi Marcus Philip added a comment -

          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?

          Show
          marcus_phi Marcus Philip added a comment - 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?
          Hide
          marcus_phi Marcus Philip added a comment -

          Pipeline with individual cycle and build times and stats.

          Show
          marcus_phi Marcus Philip added a comment - Pipeline with individual cycle and build times and stats.
          Hide
          zihaoyuhbo Zihao Yu added a comment -

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

          Show
          zihaoyuhbo Zihao Yu added a comment - Great suggestion. I will work more on that. Meanwhile I'm going to close the PR and lower the priority of this JIRA.
          Hide
          pmatignon Patrice Matignon added a comment -

          I would love to see this feature come to fruition. Let me know if I can help.

          Show
          pmatignon Patrice Matignon added a comment - I would love to see this feature come to fruition. Let me know if I can help.
          Show
          patbos Patrik Boström added a comment - Merged PR https://github.com/Diabol/delivery-pipeline-plugin/pull/103
          Hide
          patbos Patrik Boström added a comment -

          Release in 0.9.4

          Show
          patbos Patrik Boström added a comment - Release in 0.9.4
          Hide
          pmatignon Patrice Matignon added a comment -

          Thank you all for this great feature, very useful!

          I am using v0.9.5 and I see that the build times are reported as the sum of the build times for all steps. However, earlier in this thread, there was a discussion about the concurrent steps that should not be counted twice. So in this version, it does not seem to be implemented.
          Could you please clarify?

          And if confirmed, what is the general sense of what the logic should be?
          IMHO, I see value in different scenarios:

          • Actual build times, excluding concurrent steps (i.e. actual time spent building steps)
          • Total end-to-end times (pipeline time to complete), including the inactive time in case of MANUAL triggers
            So, and realizing this adds complexity, maybe a configuration for potentially multiple displays:
            [ ] show total build times
            [ ] show actual build times
            [ ] show end-to-end pipeline duration
            What is your sense, so that we can decide if a follow-up enhancement ticket should be created ? Thanks in advance!
          Show
          pmatignon Patrice Matignon added a comment - Thank you all for this great feature, very useful! I am using v0.9.5 and I see that the build times are reported as the sum of the build times for all steps. However, earlier in this thread, there was a discussion about the concurrent steps that should not be counted twice. So in this version, it does not seem to be implemented. Could you please clarify? And if confirmed, what is the general sense of what the logic should be? IMHO, I see value in different scenarios: Actual build times, excluding concurrent steps (i.e. actual time spent building steps) Total end-to-end times (pipeline time to complete), including the inactive time in case of MANUAL triggers So, and realizing this adds complexity, maybe a configuration for potentially multiple displays: [ ] show total build times [ ] show actual build times [ ] show end-to-end pipeline duration What is your sense, so that we can decide if a follow-up enhancement ticket should be created ? Thanks in advance!
          Hide
          denisby Denis Kot added a comment -

          Is it possible to use this feature in messages? I.e. in HipChat messages. Like:

          job-pipeline #3007 SUCCESSFUL after 1 min 42 sec
          
          Show
          denisby Denis Kot added a comment - Is it possible to use this feature in messages? I.e. in HipChat messages. Like: job-pipeline #3007 SUCCESSFUL after 1 min 42 sec

            People

            • Assignee:
              Unassigned
              Reporter:
              zihaoyuhbo Zihao Yu
            • Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: