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


      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.


      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
            justinharringa Justin Harringa
            0 Vote for this issue
            2 Start watching this issue