Community Edition and SonarLint using different branches

I am setting up SonarQube and SonarLint in Visual Studio Code.

I have install SonarQube Community edition 9.6.1 and it is up and running fine.

I set up Jenkins to analyze one of my GitHub projects using the latest Jenkins SonarQube Scanner version 4.7.0. That also seems to work fine.

My project is using git with ‘master’ and ‘dev’ branches.

I run a Jenkins build that checked out and analyzed a feature branch from ‘dev’. This worked fine and uploaded to scan results to my SonarQube server where I could see the results.

So far so good.

Now I am trying to set up SonarLint version 3.9.0 in Visual Studio Code to show the scan results in the code there.

Here is where I am running into a problem. I see in all of the documentation and comments and help that in SonarQube Community edition the results will always be assigned to a branch called ‘master’, regardless of which branch was analyzed. Fair enough. However, in my SonarQube it shows the branch as ‘dev’ not ‘master’. I do not know why. I cannot change it, of course, and if I click on it I am asked to install the Developer edition, as expected.

image

My problem is that SonarLint is asking for information from the ‘master’ branch in SonarQube. That does not match the ‘dev’ branch shown in SonarQube so I get no scan data in Visual Studio Code (the log shows everything working except for the issue download calls which ask for ‘master’ and get “not found” responses).

image

What do I do now? I seem to only get results in ‘dev’ on SonarQube but I can only fetch results from ‘master’ in SonarLint.

Is there some change in behavior recently with SonarQube? I was expecting to only see a ‘master’ branch, which would match with SonarLint.

Hello, welcome to the community! And thanks for reporting this behavior.

In theory, SonarLint should try to use the closest branch or default to the one that SonarQube reports as the “main” branch for the project, and only default to master when it has no clue.

Please note that we released a new version of SonarLint for VSCode last week, which includes a fix for this behavior.