I’m having an issue with a Test task deleting all old JUnit XML results. This seems to have been introduced in my build somewhere in the later releases… I’m just seeing it now. I’m currently at 4.8. This is a highly customized Test task with lots of configured options, which I didn’t paste here for clarity sake, but I could if necessary.
Here is the debug from a Test task execution. It starts the
Delete old JUnit XML results process. This is a highly customized Test task with lots of configured options. This is not default behavior, is it? I must be introducing this somehow.
17:45:16.705 [DEBUG] [TestEventLogger] Gradle Test Executor 6 PASSED
17:45:16.728 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: SUCCEEDED
17:45:16.728 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'Gradle Test Executor 6' finished with exit value 0 (state: SUCCEEDED)
17:45:16.729 [DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1.116.119 completed (1 worker(s) in use)
17:45:16.729 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Dispatch org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor@63bc5780: released lock on root.1.116.119
17:45:16.730 [DEBUG] [TestEventLogger]
17:45:16.730 [DEBUG] [TestEventLogger] Gradle Test Run :obi:sample-12c:regressionBaselineTest PASSED
17:45:16.730 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Delete old JUnit XML results' started
17:45:16.730 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Delete old JUnit XML results'
17:45:16.730 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Delete old JUnit XML results' completed
I should have mentioned that XML files from other test classes are being deleted. It’s very strange. I haven’t definitively verified that it’s this build operation that’s doing it. But it’s the only mention in the debug of deleting previous test XML files.
This is the default behavior. Otherwise you’d end up with stale XML files if test classes are deleted or renamed. As long as each
Test task uses its own output directory (which it does by default), this shouldn’t be causing any problems.
Thanks for answering Fred. That was indeed the problem… I am writing to a custom
reports.junitXml.destination location and had been writing multiple JUnit files there. Until recently… Gradle was not clobbering the entire contents of that directory… I’m not sure when that changed. So I made the change to writing to isolated directories and all is well. Thanks again.
What criteria does Gradle use to identify “old” JUnit result files? We have some tests that manually write out XML test result files in the JUnit format into the results dir for certain types of failures, but we recently discovered that these files have been getting silently deleted ever since we upgraded Gradle (which has caused a number of failures to go unnoticed which is not ideal).
The files are being written out by the JVM running the JUnit tests, so it seems odd that Gradle would somehow being identifying them as “old”. Is there any way to prevent or alter this auto-cleanup logic for JUnit result files?
For anyone else who runs into this problem, we ended up hacking around the new auto-deletion behavior by modifying our test code to write the “fake” result files to a different directory entirely. Then, we added a
doLast block to our
Test task in gradle to copy all the results from this other directory to the standard JUnit results directory (it seems that the
doLast block ends up executing after the automatic purging has already occurred).