Get report for multiple product flavors

[houpps (Peter Prip-Sørensen)]

Hi,

I’m having some trouble setting up sonar cloud for an android app build. The build runs as gradle build in a bitbucket pipeline.

below is how sonar cloud in configured in the bitbucket-pipeline.yml

# Build release version
- ./gradlew assembleRelease
# Build debug version
- ./gradlew assembleDebug
# Run unit tests for all variants.
# Run coverage
# Run Sonar
- ./gradlew --stacktrace test
- ./gradlew --stacktrace jacocoTestReport
- ./gradlew --stacktrace sonarqube

The sonarqube part of build.gradle

sonarqube {
        properties {
            property "sonar.sourceEncoding", "UTF-8"
            property "sonar.projectName", "App"
            property 'sonar.exclusions', ....
            property 'sonar.coverage.jacoco.xmlReportPaths', file(...)
       }
}

The android app have two flavors but I’m only able to get sonar cloud to report on what ever flavor is built last by the assembleDebug.

[OlivierK (Olivier Korach)]

Hello @houpps,

Welcome to the SonarSource community. . We hope you’ll enjoy it

What you describe is quite normal. Every subsequence analysis f a project with the same project key supersedes the previous one.
So if you perform 2 builds of 2 different flavors of your apps and you scan them in succession with the same project key, then you always only see the results of the last scan.

To avoid this there are 3 workarounds to this

1. Discriminate the 2 flavors with a different project key
You can explicitly set a different project key for the 2 different flavors (sonar.projectKey=myapp_flavor_A and sonar.projectKey=myapp_flavor_B) between the 2 builds/scans.

Whether the above is useful is often debated, and depends on how much code is in common between the 2 flavors, because when you scan the 2 flavors as 2 different projects:

• If that’s private projects, the full code of each projects accounts for your lines of code subscription (in other words, the common code is counted twice)
• The same issues on the same code of the 2 flavors is reported twice

It all depends on how much code is different between the 2 flavors and how badly your need to have an exhaustive code of all the code variations across your flavors.

2. Analyze one of the flavors as a long lived branch of the main flavor
Instead of using a different project key you can set the sonar.branch.name parameter for one of the 2 flavors so that it is presented as a separate “branch” of the same project in SonarCloud.

This had the advantage that you don’t have 2 different projects and lines of codes are not counted twice.
The main drawback is if you also have “branches” in your project that are really SCM branches. This kinds of mixes up the concept of “flavor” branches (same code base,but built differently) and SCM branches (different code base). All branch types are mixed in the branch menu.
If can become a nightmare if analyze short lived branches too. Because you may have 2 instances of the same short lived branch, one for the build branch flavor_A and the other for build branch flavor_B

3. Analyze only one flavor
Given that none of the above 2 solutions are a perfect fit, some SonarQube users who know that the code of a 2nd build flavor is only different from the 1st by a very few lines, take the decision to analyze only one flavor.

Up to you to decide what of the 3 options is the most suitable for you.

Olivier