The duration_ms is now broken on Jenkins

[gibfahn]

• Subsystem: test, jenkins

As previously mentioned here, the Jenkins TAP plugin introduced a breaking change, so duration_ms really does now mean duration in milliseconds. However, the total time taken (top right in the screenshot) still assumes duration_ms is in seconds (as it used to be, and as tools/test.py assumes it to be).

There's been no response to @rvagg's comment on the Jenkins TAP plugin PR, but I assume that's because it's not actively developed.

I'd suggest that the way forward is to submit a PR to the TAP plugin adding duration, and then update our scripts to use that.

Related:
Jenkins plugin PR: jenkinsci/tap-plugin#6 (comment)
#7133 #7216 #7214

[gdams]

raised an issue here: https://issues.jenkins-ci.org/browse/JENKINS-40033

[jbergstroem]

My idea of the way forward here is replacing the tap plugin with tap2junit which will then produce proper junit output. This solves not only this issue but also the slowdown's we've been facing in jenkins for a long time.

[jbergstroem]

Whats left to do is more testing plus making sure all workers have pip/tap2junit installed. At least AIX and debian7 hosts still lacks it. I have a fix for the later in my build branch.

[evanlucas]

@gibfahn is this still an issue?

[gibfahn]

@evanlucas yes it's still an issue, the duration reporting in Jenkins is still wrong.

[Trott]

I don't get the problem with the time presented in the upper right. In the screenshot in this issue, 5min 18sec is surely the right duration for all the tests to run, not something 1000 times smaller or larger. What am I overlooking?

[gibfahn]

I don't get the problem with the time presented in the upper right. In the screenshot in this issue, 5min 18sec is surely the right duration for all the tests to run, not something 1000 times smaller or larger. What am I overlooking?

That's the time it took the job to run, Jenkins has no problem with that as it's a Jenkins native measurement.

The problem is the duration of each of the individual tests. They all show 0ms because their duration has been divided by 1000. The parsing of the duration_ms output of each test is the issue.

[Trott]

Am I wrong to think this is now fixed?