Best Practice for SonarQube Analysis of Multi-Module Projects (Spring Boot, Kotlin, Swift)

[Abishek_Haththakage]

Must-share information

• SonarQube Server Version: Community Edition (running on Docker in an Azure VM)

• SonarQube Scanner: Using SonarQubePrepare@7, SonarQubeAnalyze@7, and SonarQubePublish@7 tasks in Azure DevOps

• Languages/Projects: Spring Boot (Java), Swift, and Kotlin – multi-module projects

• Azure DevOps Pipeline: Running on hosted agents (Ubuntu/macOS depending on the module)

---

Deployment Details

• SonarQube is deployed using Docker on an Azure VM.

• The pipeline is running in Azure DevOps with Community Edition integration.

---

What I am trying to achieve

I want to analyze a multi-module project (Java + Kotlin + Swift) with SonarQube in Azure DevOps.
Currently, I am using the sonar.modules + bind project approach to configure submodules manually.

Here is the snippet I am using:

- task: SonarQubePrepare@7
  displayName: 'Prepare SonarQube Analysis'
  inputs:
    SonarQube: 'sonar'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: '$(SONAR_PROJECT_KEY)'
    cliProjectName: 'server'
    cliSources: '.'
    extraProperties: |
      sonar.projectVersion=1.0.2
      sonar.sourceEncoding=UTF-8
      sonar.exclusions=Dockerfile

      sonar.modules=app,assets-module,core-module,kpi-module

      app.sonar.projectBaseDir=app
      app.sonar.sources=src/main/java
      app.sonar.java.binaries=build/classes/java/main

      assets-module.sonar.projectBaseDir=assets-module
      assets-module.sonar.sources=.
      assets-module.sonar.java.binaries=.

      core-module.sonar.projectBaseDir=core-module
      core-module.sonar.sources=.
      core-module.sonar.java.binaries=.

      kpi-module.sonar.projectBaseDir=kpi-module
      kpi-module.sonar.sources=.
      kpi-module.sonar.java.binaries=.

---

What I have tried so far

• Used sonar.modules to define submodules manually.

• Used bind project approach in Azure DevOps.

• Successfully ran analysis, but I am unsure if this is the best practice for multi-module projects.

---

Question

• Is using bind project + sonar.modules the correct approach for multi-module (Spring Boot + Kotlin + Swift) projects?

• What are the disadvantages of using bind project in this setup?

• What is the recommended best practice for configuring SonarQube in Azure DevOps pipelines for multi-module projects?

[ganncamp (G Ann Campbell)]

Hi,

@Abishek_Haththakage

Successfully ran analysis, but I am unsure if this is the best practice for multi-module projects.

How do you build? The best practice is generally to use the SonarScanner that corresponds to your build tool. For Java & Kotlin, that’s going to be the SonarScanner for Maven or the SonarScanner for Gradle. Since Google is telling me you can also build Swift with Gradle, I’ll assume that’s what you’re doing & say you should just use the SS4Gradle.

The benefit of using the scanner tailored for your build environment is that it reads most of the configuration it needs out of that environment. That means you don’t need that module configuration since it should all be read from the env.

That said, both the SS4Maven and the SS4Gradle have a (probably understandable) Java bias, so even though you’re building the Swift with Gradle, you may still need to turn on sonar.gradle.scanAll=true to get the non-Java/Kotlin files picked up.

 
HTH,
Ann

[Abishek_Haththakage]

Hi Ann,

Thanks for the guidance! Just to clarify our setup:

• Java Spring Boot is a separate backend project with multiple modules.

• Kotlin is a separate mobile project.

• Swift is a separate native iOS project.

Since these are completely independent projects, we are currently using the Azure DevOps SonarQube tasks (Prepare/Analyze/Publish) individually for each project. For the Java Spring Boot project, we are still using sonar.modules to define submodules, while the Kotlin project is configured with the CLI scanner, and the Swift project is yet to be configured.

Given this separation, would it be okay to continue using the Azure DevOps SonarQube actions for each project individually, or would you recommend switching to the build-tool-specific scanners for any of these projects?

Thanks again for your advice!

Best regards,
Abishek Haththakage

[ganncamp (G Ann Campbell)]

Hi Abishek,

Since you build these three projects separately, then yes you should (continue to) analyze them separately. I would recommend switching to the native SonarScanners that match your build systems. Then you won’t need to define your modules manually.

 
HTH,
Ann