Version: Data Center Edition - Version 10.4.1 (build 88267)
Hi, I visited your booth a few weeks ago at WAD2024 were we discussed the following issue:
We currently have a Gradle project with multiple included builds.
Whenever we try to run the sonar plugin on this we only receive the results of the first build and not the other builds.
We are aware that we can just put every build in a separate sonarqube project. However, for ease of use, clarity, etc. we want the results in a single project.
Weāve already tried the JaCoCo aggregation but to no success.
As requested we have created a small demo project with a simplified version of what we are running. I have attached it to this post. sonartest-main.zip (67.6 KB)
Any advice or pointer would be great!
Thanks in advance.
hmm, 1st thought: how should this be tackled communication-wise? is this something for PM4AD like āI wish me a gradle build that also includes includedBuild(s)ā (plus the ālet me try to better understand what you are trying to archieveā-dance )?
2nd thought: it is already a week old, lets bump it a bit by formulating a reply
3rd thought: i see āData Center Editionā, i realize money involved ā¦ thank you, wouter, for not trying to wiggle yourself to a private solution but to tackle this in the open! (and for creating the example project, too)
Hello @WouterB and welcome to the Sonar Community.
Thank you for providing the small demo project, it will definitely help the investigation. I will have a look at the old threads to try out the proposed solutions. Meanwhile can I ask you to try setting to true the property sonar.gradle.scanAll? This property allows indexing files outside of conventional sources and Iām interested in knowing your feedback.
Can you describe me what exactly do you expect to see when analyzing a Gradle project with multiple included builds? What is missing?
Hello Angelo and thank you for the welcome as well as the response.
To add a bit more context, the project in question that weād like to analyze is a giant Java project. This used to be a maven project for which we had the sonar scanner running properly. But the past few years we made the switch to Gradle which got us in a pickle.
Iāve tried setting the sonar.gradle.scanAll property to true and for the test project this seems to do what we would like to see, albeit with more files than only our JVM related files.
Setting it on our intended project seems to introduce a bunch of memory and potentially network related issues due to the sheer size of the project. It having to handle more files than only our Java files, reading and processing them seems to be quite the struggle.
Iām also not sure that this wouldnāt create a mess in the SonarQube project.
The original problem is that when not running with the scanAll property, only the top level build is processed on the instance. (e.g. for the test project this would only be āsrc/main/java/sonartestā instead of all the other included builds.) But we would like to have it show all modules/directories and not only the top level.
Hello @WouterB, thank you for providing more context and testing the sonar.gradle.scanAll property.
I did more research about the included builds and the documentation highlights that they execute in isolation, and it is preserved also in the Gradle API. The sonar-scanner-gradle is a Gradle plugin and the project structure it can access is, by design from Gradle, isolated from included builds.
Unfortunately, there is no clean way of gluing together the included builds as a whole project for a Sonar Analysis.
As a consequence, I believe that the sonar.gradle.scanAll should not analyze any file from included builds to preserve the design choice of isolation. The [SCANGRADLE-154] - Jira contains more details.
Could you please provide more feedback about the memory and network issues that you experienced when enabling the sonar.gradle.scanAll property?
The memory issues were of the metaspace type that Iāve encountered here on the forum as well. Upping the memory values in the settings solved this issue.
We didnāt continue our search for the network issue as we decided to try a new route in finding a solution.
We decided to look into the āApplicationā possibility that is provided with our edition of SonarQube. We created a project for each included build and we let it run itās own scan when running the root scan and then have it send itās result to itās own project.
The Application view is much better than expected (and than how it was explained to me) so in the end this looks like a much better solution for us.
We wonāt be using the projects view in it as itās kind of an artificial split up but the other view works like we want it to.