which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
what are you trying to achieve
what have you tried so far to achieve this
On top of answering those questions, can you clarify whether you are running several SonarScanner processes in parallel on your pipeline? From your pipeline design and the IO related error, I am thinking you may be getting into trouble due to executing 2 or more SonarScanner processes concurrently on the “Commit2” stage which operate on the same path. So, let’s start from there.
Hi @Daniel_Meppiel, how are you? Thanks a lot for your feedback. @Ramon_Sobreira will provide all information soon, but meanwhile, I would like to give you further information.
Basically, our devsecops framework is split into two parts: COMMIT stage and DEPLOYMENT stage. Now, we are talking about the first one which begins with a change to the state of the project/application —that is, a commit to the version control system, compile code, run unit tests and some integration tests (when it exists), perform quality analysis of the code, prepare artifacts to use in later stage of pipeline – binaries. Include a version number into a bundle of the entire solution. Then, it ends with either a report of failure or, if successful, a collection of binary artifacts and deployable assemblies to be used in subsequent test and release stages, as well as reports on the state of the application.
Particularly, there are repositories in the web-based version control repository hosting service that have more than one project or source code. For this scenario, it is possible to process the steps above in paralell in the same ci/cd pipeline.
At the beginning, that error rarely occurred due to we only had 2 projects and probably because we were in the onboarding phase, but now we have several structures which have 4, 6 projects or so in the same repository, then this error frenquently happens during this process.
Therefore, we would like to know if there is a solution for this problem. Otherwise, what’s the procedure to open an enhancement request to the SonarQube Developers to assess that? And if it is accepted, I don’t have any doubt this may help us and the entire community a lot.
I am more convinced now that you are running into a “race condition” where multiple SonarQube scans are running in parallel and may be overwriting/reading from the same folder. The scanners needs to create their temporary storage folder under /tmp/.sonarqube, so you need to make sure this location is used by a single scanner once at a time. With 6 scanners running in parallel and all of them using the same temporary folder for their work, anything and everything can happen.
Just so you know, SonarQube does not offer for now a clean/seamless way to manage your scenario as of today, although it is in our vision to provide Monorepo support as SonarCloud already does. So you probably need to work in isolating/disentangling the execution of the 6 scanners or execute a single scan for the entire repository.
@Daniel_Meppiel, I’m assessing your return, but I agree with your feedback. We work with BITBUCKET, however, the behaviour that you described matches with the situations that are faced by us.
Hello @Daniel_Meppiel, how are you? @Jefferson_Dias and I identified a great solution that worked very well to our case. Basically, we set TMPDIR up before running the sonarscanner begin and it takes the appropriated directory that is specified by each application so even when they run the processes in pararell, this CLI below works with their respective temporary folder due to this environment variable belongs to the operating system and it seems the sonarscanner uses it instead of working with the file system hard-coded.
We used this material to support us in this implementation:
Finally, we would like to suggest if it is possible to update the documentation when there are CI/CD pipelines running in parallel or with concurrent builds, so this can be applicable for several users that are facing the same situation.
I am glad you could find the solution above. And thanks for posting the workaround here, really valuable.
I am now checking internally whether this may be reflecting an issue on the SonarScanner for MSBuild and the best path of action for us. I’ll keep you posted.
