You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Eliminate checkpoint at the end of tests in Jenkins #165
After running all the tests, Jenkins test jobs block until the previous job is complete. As seen on the output of job 277:
Publish TAP Results is waiting for a checkpoint on node-test-commit-arm » pi1-raspbian-wheezy #276
It this case, a previous job (273) was compiling and for some reason ccache did not seem to help. It took 9h35m, and jobs started afterwards had to wait for it to finish before they could publish the results.
I don't know why this checkpoint is there, the only reason I can think of is to display the comparison in the TAP output, such as TAP Test Results (2 failures / +2).
So,
Is this the only reason for this checkpoint?
Is it consensual that this is useless for our use case?
For things like our jobs that test and land pull requests, it's certainly useless. Computing the delta in failures between different PRs, and across multiple branches doesn't add a lot of value. The failure delta might make more sense in more traditional type of CI jobs that run periodically on the same branch. In that category we currently have only node-daily-master. But if the side effect is that a job needs to block on other runs just to report the results, I am definitely in favor of removing that feature.
Test a our plugin with a clone of of one of the test jobs, e.g. node-test-commit-unix
Fix checkpoint issue by modifying plug-in code. Hopefully something like jenkinsci/slack-plugin@832e7b5
Test again in our Jenkins
Provided it works, update all our node-test-commit-* jobs to use the new plugin instead of the TAP plugin, making sure all configuration for it is the same
Closing as this has been inactive for over a year and I believe we intend to move off the TAP plugin. Feel free to re-open or comment if I am mistaken to close this.
Activity
orangemocha commentedon Aug 24, 2015
For things like our jobs that test and land pull requests, it's certainly useless. Computing the delta in failures between different PRs, and across multiple branches doesn't add a lot of value. The failure delta might make more sense in more traditional type of CI jobs that run periodically on the same branch. In that category we currently have only node-daily-master. But if the side effect is that a job needs to block on other runs just to report the results, I am definitely in favor of removing that feature.
orangemocha commentedon Aug 28, 2015
It looks like we are going to have to modify the TAP plugin: https://issues.jenkins-ci.org/browse/JENKINS-29650
orangemocha commentedon Aug 28, 2015
Also relevant: https://issues.jenkins-ci.org/browse/JENKINS-9913
jbergstroem commentedon Aug 31, 2015
@orangemocha how do you suggest we proceed here? Doesn't look like upstream jenkins/tap plugin is moving forward anytime soon.
orangemocha commentedon Aug 31, 2015
Test again in our Jenkins
Trott commentedon Oct 24, 2016
Closing as this has been inactive for over a year and I believe we intend to move off the TAP plugin. Feel free to re-open or comment if I am mistaken to close this.