Gradle Test Task is deleting old JUnit files


(Stewart Bryson) #1

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

(Stewart Bryson) #2

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.


(Fred Curts) #3

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.


(Stewart Bryson) #4

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.