SonarCloud not analyzing subprojects in Gradle multi-project build

ALM & CI system: Azure DevOps
Scanner: SonarQube plugin version “4.4.1.3373”

Hi, when i run the Sonar scanner as part of my gradle multi-project build, the analysis only covers the files of the root folder, but not of the subprojects.
BUT, when i instead use the dedicated SonarCloudAnalyze task and let it run immediately after the gradle build task, all subprojects are analyzed. Why does it behave differently?

Here is my sonar config from build.gradle.kts:

plugins {
	...
    id("org.sonarqube") version "4.4.1.3373"
}

sonar {
    properties {
        property("sonar.projectKey", "...")
        property("sonar.projectName", "...")
    }
}

subprojects {
    ...
    apply(plugin = "org.sonarqube")

    sonar {
        properties {
            property("sonar.language", "java")
            property("sonar.inclusions", "**/*.java")
            property("sonar.sourceEncoding", "UTF-8")
            if (file("src/main/java").exists()) {
                property("sonar.sources", "src/main/java")
                property("sonar.java.binaries", "${buildDir}/classes/java/main")
            }
   	}
    }
}

And of course in the settings.gradle, all subprojects are included.

Here is the config of the SonarCloudPrepare task when i used the scanner as part of gradle build:

steps:
  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: '...'
      organization: '...'
      scannerMode: 'Other'
      extraProperties: |
        # Additional properties that will be passed to the scanner,
        # Put one key=value per line, example:
        sonar.projectKey=...
        sonar.projectName=...
        sonar.verbose=true

And this is the config of the SonarCloudPrepare task when i used the dedicated scanner of SonarCloudAnalyze task:

steps:
  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: '...'
      organization: '...'
      scannerMode: 'CLI'
      configMode: 'manual'
      cliProjectKey: '...'
      cliProjectName: '...'
      extraProperties: |
        # Additional properties that will be passed to the scanner,
        # Put one key=value per line, example:
        sonar.java.binaries=$(System.DefaultWorkingDirectory)/**/target/classes/java/main
        sonar.inclusions=**/*.java
        sonar.verbose=true

I have seen other users mentioning the same issue with a gradle multi-project build, but unfortunately the solution was not posted in the thread, like here:

Hey there.

Let’s try and simplify things.

As noted in the docs:

To analyze a project hierarchy, apply the SonarQube plugin to the root project of the hierarchy. Typically (but not necessarily) this will be the root project of the Gradle build.

Therefore, this is not needed and may be getting in the way:

I would also suggest that you go ahead and remove all additional configurations (and attempts to use the CLI scanner instead of the Gradle scanner). This should not be needed.

Thanks @Colin for your support, i tried what you suggested but it still is the same result.
Only the files from the root folder are shown in analysis result:

This looks like the results from a Pull Request Analysis, which will only show changed lines of changed files. In good news – it looks like that worked fine! I would bet that when you merge into your main branch, you’ll see the full results.

You could also test this by making a change to one of your “real” source files in a subfolder in the context of this PR.

(By the way, I am already regularly giving feedback internally that this is a confusing experience for a user’s first analysis.)

1 Like

Its the analysis of a feature branch in which i tested the configuration of Sonar Cloud plugin, but no pull request. And with the CLI scanner, it worked on the same branch and showed the full analysis result.

A short-lived branch will behave the same way.

1 Like

Oh no :smiley: i was not aware of this! This explains it for sure… thanks a lot for your support @Colin

But still its a bit odd that the CLI scanner produces a different/full analysis on the same branch

I’m not sure how to explain that unless it got analyzed as a long-lived branch, or some other change was impacting the detection of changed lines.

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