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

Run.duration is calculated after RunListener.fireCompleted in WorkflowRun whereas it is calculated before in core Jenkins' Run class

    XMLWordPrintable

Details

    Description

      In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

      Is this intentional?

      Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

      WorkflowRun code

      Core Jenkins Run code

       

      In short, this PR gives us better metrics and a consistent interface to get build time metrics.

      Scenario:

      MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

      WorkflowRun.duration: always 0

      hudson.model.Run.duration: calculated based on start and end time.

      So, essentially, there is an inconsistency in the expectation of duration being available and the fact that a RunListener would need to calculate the duration puts the RunListener in a situation where they may not be calculating it in a consistent moment.

      Attachments

        Issue Links

          Activity

            justinharringa Justin Harringa created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Assignee Justin Harringa [ justinharringa ]
            jglick Jesse Glick made changes -
            Remote Link This issue links to "PR 72 (Web Link)" [ 17788 ]
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            jglick Jesse Glick made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            justinharringa Justin Harringa made changes -
            Description In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

             

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]
            In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]

             
            h3. Scenario:

            MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

            {{WorkflowRun.duration: always 0}}

            {{hudson.model.Run.duration: calculated based on start and end time.}}

             
            justinharringa Justin Harringa made changes -
            Description In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]

             
            h3. Scenario:

            MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

            {{WorkflowRun.duration: always 0}}

            {{hudson.model.Run.duration: calculated based on start and end time.}}

             
            In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]

             
            h3. Scenario:

            MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

            {{WorkflowRun.duration: always 0}}

            {{hudson.model.Run.duration: calculated based on start and end time.}}

            So, essentially, there is an inconsistency in the expectation of duration being available and the fact that a RunListener would need to calculate the duration puts the RunListener in a situation where they may not be calculating it in a consistent moment.
            justinharringa Justin Harringa made changes -
            Description In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]

             
            h3. Scenario:

            MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

            {{WorkflowRun.duration: always 0}}

            {{hudson.model.Run.duration: calculated based on start and end time.}}

            So, essentially, there is an inconsistency in the expectation of duration being available and the fact that a RunListener would need to calculate the duration puts the RunListener in a situation where they may not be calculating it in a consistent moment.
            In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

            Is this intentional?

            Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

            [WorkflowRun code|https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L676]

            [Core Jenkins Run code|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L1758]

             

            In short, this PR gives us better metrics and a consistent interface to get build time metrics.
            h3. Scenario:

            MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

            {{WorkflowRun.duration: always 0}}

            {{hudson.model.Run.duration: calculated based on start and end time.}}

            So, essentially, there is an inconsistency in the expectation of duration being available and the fact that a RunListener would need to calculate the duration puts the RunListener in a situation where they may not be calculating it in a consistent moment.
            justinharringa Justin Harringa made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]

            People

              justinharringa Justin Harringa
              justinharringa Justin Harringa
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: