Short-lived branch analysis seems to be empty

SonarQube Cloud
1

I’m using the gradle sonarqube plugin (2.6.2) to analyse a Java project, using CircleCI.

It’s analysing the master branch fine, but when I use ‘-Dsonar.branch.name’ to analyse a feature branch the analysis runs through and the branch is created within sonarcloud, but the code is empty and there are no issues listed.

Am I doing something wrong here?

  - run:
      name: SonarQube analysis
      command: |
        gradle sonarqube \
            -Dsonar.login=$SONAR_LOGIN\
            -Dsonar.branch.name=$CIRCLE_BRANCH

Note that the other sonar properties (organisation, project, etc) are set from within the gradle build, and it’s creating the branch in sonar in the correct project so the connection to sonar seems to be working.

2

Hi,

Just to be sure, can you send a screenshot of a branch’s Code page?

 
Ann

3

Hi Ann

Here’s what the code screen looks like - empty!

47
Screen Shot 2018-11-14 at 15.53.47.png2586×624 36.4 KB

Any ideas?

Thanks,

Ash

4

Hi Ash,

Yep. That’s empty. :slight_smile:

Honestly, I was hoping you were speaking metaphorically. Clearly not.

So now for some details:

  • What version are you on?
  • This is specifically a SLB analysis and not a PR?
  • Did you by chance delete more lines than you added or modified?

 
Ann

5

Hi Ann,

I’m using SonarCloud. I’m using version 2.6.2 of the gradle plugin.

Yeah, it’s a SLB analysis using sonar.branch.name. It’s creating the branch in the UI so something’s working, there’s just no code!

This was on a test commit where I only added a couple of lines where I would expect an issue to be raised (an unchecked nullable access).

I’ve also checked all the branches (there are quite a few) that the team have created and they’re all blank too.

Thanks,

Ash

6

Hi Ash,

Doh! Sorry I missed that.

Did you explicitly specify the target branch, or let it default to master? And if the latter, could you try making explicit?

 
Ann

7

I hadn’t explicitly set the target branch, so tried explicitly setting it to master and it’s still the same (no code or issues shown)

gradle sonarqube \
    -Dsonar.login=$SONAR_LOGIN \
    -Dsonar.branch.name=$CIRCLE_BRANCH \
    -Dsonar.branch.target=master \
    --debug

I’m running gradle in debug mode and it looks like it’s successfully creating a report (size = ~1MB) and uploading it with a 200. It’s just not showing anything in the UI.

18:40:36.174 [INFO] [org.sonarqube.gradle.SonarQubeTask] Analysis report generated in 392ms, dir size=1 MB
18:40:36.782 [INFO] [org.sonarqube.gradle.SonarQubeTask] Analysis reports compressed in 607ms, zip size=947 KB
18:40:36.782 [INFO] [org.sonarqube.gradle.SonarQubeTask] Analysis report generated in /home/circleci/app/build/sonar/scanner-report
18:40:36.782 [DEBUG] [org.sonarqube.gradle.SonarQubeTask] Upload report
18:40:38.211 [DEBUG] [org.sonarqube.gradle.SonarQubeTask] POST 200 https://sonarcloud.io/api/ce/submit?organization=xxxxxxxxxxx&projectKey=xxxxxxxxxxx&projectName=xxxxxxxxxxx&characteristic=branch%3Dsonar&characteristic=branchType%3DSHORT | time=1428ms
18:40:38.213 [INFO] [org.sonarqube.gradle.SonarQubeTask] Analysis report uploaded in 1430ms
18:40:38.215 [INFO] [org.sonarqube.gradle.SonarQubeTask] ANALYSIS SUCCESSFUL, you can browse https://sonarcloud.io/dashboard?id=xxxxxxxxxxx&branch=sonar&resolved=false
9

Any ideas on this?

I’ve set up a new project and it’s doing the same thing - the master is analysed fine, but the SLBs are all empty. Interestingly I noticed that the coverage estimation is different on each of the SLBs, so there is something happening somewhere!

10

Did you come to a resolution on this? I am experiencing the exact same issue but using AppVeyor for CI.

12

We’re having the exact same issue. We are triggering the builds + analysis in bitbucket pipelines.

Here is our pipelines yml file bitbucket-pipelines.yml.txt (2.7 KB)

Our core long term branch is develop. When ever the develop build is triggered, the sonarcloud is updated correctly.

However, if I trigger a custom build “Sonarcloud” from a branch, the branch appears in sonarcloud, but its empty. exactly like the others:

empty_build
empty_build.PNG1370×354 13.9 KB

13

This is the expected behaviour if your branch is considered as “short-lived”. Only the new and modified files, compared to the “target branch”, are displayed and can contain issues.
By default branches are short-lived if their name does not start with “branch” nor “release”.
Is it your case?
See https://sonarcloud.io/documentation/branches/overview/ for more details.

1 Like
14

Having the same issue with my builds from AWS Codebuild running sonarscanner for msbuild: https://github.com/SonarSource/sonar-scanner-msbuild/releases/download/4.4.2.1543/sonar-scanner-msbuild-4.4.2.1543-netcoreapp2.0.zip

I get the correct results in my long term branch, but in my short term branch it only displays some of the projects and with faulty information:

slb
slb.PNG1150×315 7.32 KB

15

In our case it doesn’t show any modified files or new lines, hence the issue.

Just to clarify what we do in our pipelines build script when we trigger a sonarcloud branch analysis.

  1. checkout develop branch (our long-term target branch)
  2. merge feature branch into develop branch.
  3. build and scan merged code with “sonar-scanner -Dsonar.branch.name=$BITBUCKET_BRANCH” where $BITBUCKET_BRANCH is the name of the short lives feature branch.

Could the issue be that we are analysis the post merged code?

16

Hi Ashley,

Please have a look at this topic:

There is a bug in the code checkout done by circleci.
Could you try the work arounds described there?

1 Like
17

HI,

I’m having the same issue. Initiaaly master has 400k lines of code now with short lioved branch has 390k Lines of code. When I do sonar.branch.name=shortlivedbranch. but it is empty. Please help me asap

18

Hi Ashley,

I’m having the same issue.
run:
gradle sonarqube
-Dsonar.branch.name=shortlived.
Could you tell me any tip used. When I did with out branch name it is default doing on master but when we analyse with branch name then the analysis is empty.

19

Hi,
Are you running with Circleci? If so, did you try the workaround posted in this thread?

20

No, we are running on Jenkins

21

The biggest Issue I have with this implementation is that finding newly introduced bugs on a short-lived branch is great; however, our dev teams want to know, on their short lived topic branches, that they are actually fixing issues that SonarQube is detecting, which are assigned to them, post triage. This is not happening. When an issue is assigned on the long lived branch, a dev will then take out a bugfix branch to fix the issue, build and analyze, then go to the web interface to find out if their changes have actually fixed the issue present on the long lived branch. Unfortunately, it only shows the generic “No Issues. Hooray!” message. Obviously, this is a major short-coming of SonarQube. What dev team wants to go through branch iteration, after branch iteration, which is a huge process even in an agile environment, to make sure that their bug fixes that sonar is detecting, are actually being fixed, only after their bug-fix branch is integrated into the long-lived integration, or release-candidate branch, which will then allow them to see the issue “disappear”. SonarQube, please fix this. It’s frustrating and causes a major strain on organizations who are migrating to SonarQube.

22

It was helpful. I renamed by branch to branch-oldName and sonar started reflecting the feedbacks.