Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The duration_ms is now broken on Jenkins #9784

Closed
gibfahn opened this issue Nov 24, 2016 · 8 comments
Closed

The duration_ms is now broken on Jenkins #9784

gibfahn opened this issue Nov 24, 2016 · 8 comments
Labels
test Issues and PRs related to the tests.

Comments

@gibfahn
Copy link
Member

gibfahn commented Nov 24, 2016

  • 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.

image

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

@mscdex mscdex added the test Issues and PRs related to the tests. label Nov 24, 2016
@gdams
Copy link
Member

gdams commented Nov 25, 2016

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

@jbergstroem
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

@gibfahn is this still an issue?

@gibfahn
Copy link
Member Author

gibfahn commented Apr 11, 2017

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

@Trott
Copy link
Member

Trott commented Aug 2, 2017

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
Copy link
Member Author

gibfahn commented Aug 4, 2017

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
Copy link
Member

Trott commented Oct 26, 2018

Am I wrong to think this is now fixed?
screen shot 2018-10-25 at 8 49 19 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

No branches or pull requests

7 participants