SonarCloud - no branch analysis?

  • ALM used: GitHub
  • CI system used: Drone CI
  • Scanner command used: ./gradlew core:test --tests '*ExceptionsTest' core:jacocoTestReport sonar --rerun --info (only one test for fast feedback)
  • Languages of the repository: Java
  • SonarCloud project url: JobRunr SonarCloud (project was setup without automatic analysis to support multiple branches as detailed in Automatic Analysis Doc)
  • Error observed: whatever I do, I only get one branch in SonarCloud.

Steps to reproduce:

    sonar {
        properties {
            property "sonar.sourceEncoding", "UTF-8"
            property "sonar.projectKey", "jobrunr_jobrunr"
            property "sonar.organization", "jobrunr"
            property "sonar.coverage.jacoco.xmlReportPaths", "/tmp/reports/$project.name/jacocoTestCoverage.xml"
        }
    }
  • run the scanner command above (only test only for fast feedback): ./gradlew core:test --tests '*ExceptionsTest' core:jacocoTestReport sonar --rerun --info
  • Analysis is visible in SonarCloud as master branch. So far, so good!
  • Add support for branch analysis as mentioned in docs (Branch analysis setup & SonarCloud) as below (hardcoded to omit any possible error related to environment variables)
    sonar {
        properties {
            property "sonar.sourceEncoding", "UTF-8"
            property "sonar.projectKey", "jobrunr_jobrunr"
            property "sonar.organization", "jobrunr"
            property "sonar.branch.name", "v7" // simulate branch v7 by hardcoding it
            property "sonar.branch.target", "master" // also tried v7 instead of master. Why do I even need to set this variable? I just want analysis for branch v7...
            property "sonar.coverage.jacoco.xmlReportPaths", "/tmp/reports/$project.name/jacocoTestCoverage.xml"
        }
    }
  • run the scanner command above (only test only for fast feedback): ./gradlew core:test --tests '*ExceptionsTest' core:jacocoTestReport sonar --rerun --info
  • only 1 branch available in SonarCloud

I expect to have 2 branches after the last analysis.

I had SonarCloud working with v3.5 but needed to upgrade and to be honest, I think the developer experience is not that great. I took me already almost 2 days and I’ve even deleted my SonarCloyd project (300 issues I need to revisit again :disappointed:) to try to get this to work (sorry for the venting).

And, I really hope this is not a PEBCAC issue :joy:.

Hey Ron.

Based on your most recent changes, you’re still setting sonar.branch.name to the target branch, not the branch being analyzed.

https://docs.drone.io/pipeline/environment/reference/drone-branch/

For that, you’d want DRONE_SOURCE_BRANCH

https://docs.drone.io/pipeline/environment/reference/drone-source-branch/

Hi Colin,

Thanks for the reply, appreciate it!!

Back then I was working and doing Sonar analysis on the next release branch, v7. And, the values for DRONE_BRANCH and DRONE_SOURCE_BRANCH were the same. Hence, I choose the easiest one for me :blush:.

I just tried a printenv and these are the results now for a build that is running a PR. We only do Sonar analysis on the master and v7 branch (so not each PR) so my guess will be that when I launch the sonar analysis, it will have DRONE_BRANCH= v7.

root@427b118e6f15:/drone/src# printenv | grep BRANCH
DRONE_SOURCE_BRANCH=bugfix/mutex-in-use-while-processing
DRONE_BRANCH=v7
CI_COMMIT_BRANCH=v7
DRONE_REPO_BRANCH=master
DRONE_COMMIT_BRANCH=v7
DRONE_TARGET_BRANCH=v7

So, my understanding is that in the commit you mentioned (jobrunr/build.gradle at c156b2e98fc0890888ff80c3bfd598923dfb2e88 · jobrunr/jobrunr · GitHub), the value for sonar.branch.name will have been v7. If the analysis in that case was successfull, should it not show a second v7 branch in Sonar next to the other master branch?

Ah, thanks for clarifying. My bad.

That’s my understanding now too.

Ultimately, I cloned your repo and the v7 branch and created a project in my personal SonarCloud organization. I changed the build.gradle values to connect to my org and my project and when I ran analysis… the results uploaded to your project.

So that makes me think that nothing in the sonar block of your build.gradle is impacting your build. So where is it getting the values from?

Well, it looks like they’re in your gradle.properties for the project.

systemProp.sonar.host.url=https://sonarcloud.io
systemProp.sonar.organization=jobrunr
systemProp.sonar.projectKey=jobrunr_jobrunr
systemProp.sonar.login=<redacted>

(You really need to invalidate this token ASAP. Don’t check tokens into source control. Store them as environment variables in your build.)

So why aren’t they getting overridden by what’s in your build.gradle? Well, in the end, once I moved the sonar block out of this conditional

configure(subprojects.findAll { !['platform'].contains(it.name) }) {

to right below the plugins block (as documented), it all worked as expected.

1 Like

Thank you so much :pray:, you’re the best - so it was a PEBCAC issue in the end :woozy_face:.

The funny thing is that some properties were being used as the reporting only started working once i added:

property "sonar.coverage.jacoco.xmlReportPaths", "/tmp/reports/$project.name/jacocoTestCoverage.xml"

So, some properties did get fetched from that part that’s why I was confused. Anyway, thanks again :wink:!

1 Like