I am trying to run sonar:sonar command, and I am getting this error:
Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.8.0.2131:sonar (default-cli) on project my-project: Failed to create temp file C:\Workspace\my-project\backend\target\sonar.sonartmp\scanner-report5607317958216813555.zip
hey,
we had the same problem (only after upgrading to sonar 9.4), sonar could not create the report zip because .sonartmp folder does not exist.
root cause was that we have a multi module project, and 2 /target folders were pointing to the same location. my guess is that after being done with one module sonar cleaned up (i.e. deleted the .sonartmp folder) that was still necessary to do the other module
hope it helps
@Norbert_Bauman Thanks for Sharing. I’m experiencing the same thing doing a Multi-module maven build with Sonar, running in Azure DevOps. We’ve also now seen that some multi-module maven builds with the same setup succeed. Were you able to find a solution/workaround?
I have been running locally to try and narrow down the issue to see what could be causing it.
I have created a minimal project to reproduce the problem with. If you remove test.js, you recreate the error. If you add back a .js or .html file in src/main/webapp of TestProjectWeb, you will experience the error. You will also not experience the error if you move the buildpom.xml out of the submodule and update it with new relative paths. MultiModule.zip (4.6 KB)
I have tested this with Sonar 9.4 and Sonar 9.5.0.56709 and see the same results - using this command: mvn -f TestProjectEAR/buildpom.xml org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar. The maven plugin version being used is 3.9.1.2184.
Thanks a lot for this reproducer, this greatly helps!
I was able to reproduce the problem with the latest (3.9.2184) version of the scanner, as well as a version from 2018: 3.4.1.1168, so it’s definitely not a new problem.
I’m not sure whether a fix would be made available for 9.4 or not, so before the thread closes, I wanted to describe the workaround I am using for now.
The workaround I am using currently is to add a dummy .js file in src/main/webapp of my “Web” module (the one that doesn’t share the same temporary folder with the main project) right before running analysis. Inside the file I just have a comment explaining the situation. Since we use the same build steps for many projects, this works out pretty well – allowing analysis to complete in all the projects without them making any updates and having minimal impact on the result. In our case the workaround is even less impactful, since we have separate maven runs for the actual build and the analysis (due to some projects having build plugins requiring Java <9 and this one requiring Java >9) - meaning the project doesn’t get built with the dummy .js file.