Status: Closed (View Workflow)
We have a gradle build with multiple subprojects.
Gradle can check what has been build previously and will not build again if nothing changed.
Now when changing a minor thing in the tree (like a properties file) the build will start to run, notices everyting is up to date and will not start compiling/testing/jar-ing
But at the end of the build Jenkins says: Test reports were found but none of them are new. Did tests run?
My answer is: no, because there was no use.
How do I take care of this issue?
JENKINS-10035 Not updated test reports reported as error
- is related to
JENKINS-6268 Make checking for modification time of junit results be configurable and off by default
The workaround described above is a very poor solution for Gradle builds since it tampers with the outputs of the test task. Further it adds the necessity to find out if we're running on Jenkins or a local dev build.
We're currently trying to migrate an existing Gradle CI build to Jenkins pipeline. To workaround this issue we have so far used the xUnit-Plugin which is more Gradle-friendly. With Pipeline we're not able to use xUnit anymore. Not being able to record test results is pretty much a show stopper.
Please make this behaviour configurable since it doesn't align with modern build systems.
Just found out that I actually can use xUnit plugin from Pipeline script. For anyone using Gradle and Pipeline, you can use "General build step" to have xUnit collect test results:
step([$class: 'XUnitBuilder', testTimeMargin: '3000', thresholdMode: 1, thresholds: [[$class: 'FailedThreshold', failureNewThreshold: '', failureThreshold: '20', unstableNewThreshold: '1', unstableThreshold: '0'], [$class: 'SkippedThreshold', failureNewThreshold: '', failureThreshold: '', unstableNewThreshold: '', unstableThreshold: '']], tools: [[$class: 'JUnitType', deleteOutputFiles: true, failIfNotNew: false, pattern: '**/build/test-results/*.xml', skipNoTestFiles: true, stopProcessingIfError: true]]])
Closing this issue as a duplicate. I think the problem should be fixed on the junit plugin side. The xUnit plugin already seems to fix this.
You can do as described here:
Or maybe vote for the duplicated issue?