Sonarqube Gradle plugin with included builds

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.

Over the past few years, the community already had similar questions but these havenā€™t been answered yet. (See SonarCloud doesn't seem to support composite builds in gradle - #7 by Colin and Sonarqube Gradle plugin and Composite Builds - #7 by daniel)

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.

1 Like

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 :clown_face:)?

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) :+1:

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?

Cheers,
Angelo

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.

1 Like

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?

Cheers,
Angelo

Hello Angelo

My apologies for taking a bit longer.

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.

Thanks for looking into it with us.

1 Like

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