-
versions used
- Community Edition Version 7.9.2 (build 30863)
- SonarJava 5.14 (cannot upgrade due to issue described below)
- Gradle 6.2.2
- SonarQube Gradle Plugin 2.8
- Windows (2008 R2 Server and 10 Professional)
-
error observed
-
After building, generating JaCoCo reports, and running the sonarqube task, the build directory cannot be removed.
The command line output below shows the issue, but in practice, I am not executing./gradlew clean
, instead the error occurs on my build server when it attempts to clean up the working directory.
This issue keeps me from upgrading the SonarJava plugin since v6+ requires JaCoCo XML reports.
It is important to note that this issue only arises once JaCoCo XML report output is enabled.
Another important note is the issue only occurs once the sonarqube task is executed.$ ./gradlew clean > Task :clean FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':clean'. > java.io.IOException: Unable to delete directory 'C:\sonar-test\build' Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory. - C:\sonar-test\build\reports\jacoco\test - C:\sonar-test\build\reports\jacoco - C:\sonar-test\build\reports * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 4s 1 actionable task: 1 executed
-
-
steps to reproduce
-
Create a simple Java project with the Sonar Gradle plugin and JaCoCo XML reports on.
plugins { id 'java' id 'jacoco' id 'org.sonarqube' version '2.8' } // ... jacocoTestReport { reports { xml.enabled true } }
-
Run the build, generate the reports, and execute the sonarqube task.
./gradlew build jTR sonarqube
-
Now try to clean.
./gradlew clean
-
Gradle will error. The
build/reports/jacoco/test/jacocoTestReport.xml
file is locked by the Java process.
-
-
potential workaround
- The Gradle daemon could be force stopped (i.e.,
./gradlew --stop
) on all of our CI jobs, but this is brittle and not a viable long term solution.
- The Gradle daemon could be force stopped (i.e.,
hello @tdillon,
thanks for reporting this issue. I created ticket to handle it in the next release of jacoco-plugin https://jira.sonarsource.com/browse/JACOCO-14
Is this issue resolved?
The issue has been marked as being resolved with version 1.1 of the sonar-jacoco plugin, so yes, the issue should be resolved.
@tdillon, would it be possible to know if it fixes the issue on your side?
Yes, my issue was fixed by the new version.
A side effect I wasn’t expecting is that I have to explicitly define the location of the XML file for the SonarQube plugin. e.g., property 'sonar.coverage.jacoco.xmlReportPaths', 'build/reports/jacoco/test/jacocoTestReport.xml'
. It would be nice if the SonarQube plugin would automatically identify the location based on jacocoTestReport.reports.xml.destination
.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.