Failed to create temp file

SonarQube
,
#1

Hi,

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

SonarQube instance: 9.4
sonar-maven-plugin: 3.8.0.2131
java: 11

I also tried with different OS to create a report, but the result was the same.

2 Likes
#2

Hey there.

In what context are you receiving this error? MANUAL runs? Using a specific CI (GitHub Actions, Azure DevOps, etc.)

#3

Hi,

I got this error on both my local analysis and on my jenkins instance.

#4

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

1 Like
#5

@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?

#6

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)

Here is the structure of this project/archive:

├───TestProjectEAR
│       buildpom.xml
│       pom.xml
│
└───TestProjectWeb
    │   hello.html
    │   pom.xml
    │
    └───src
        └───main
            └───webapp
                │   test.js
                │
                ├───includes
                └───WEB-INF
                        web.xml

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.

1 Like
#7

Hey @George_Snyder_Fedins

Wow – thanks for the reproducer. I was blew to reproduce the issue straight away doing this.

This helps a lot. I’ve pinged the right team who can look into this.

1 Like
#10

Hello @George_Snyder_Fedins,

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 have created a ticket to follow-up the problem.

#12

Thanks to all for the awesome support on this!

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.

3 Likes
#13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

#14

Hello @sbeki and @George_Snyder_Fedins,

The problem has been fixed. The fix will be released with SonarQube 9.6 (in August).

Aurélien

2 Likes