PR Analysis Results Inconsistent - results from master branch sometimes included

dotnet
sonarqube

(Melissa Benua) #1

I have a relatively simple branch setup in git, with two long-lived branches: master and development. We do PRs against either of those two branches, for example: feature/foo -> development or hotfix/bar -> master

We automatically do builds of those PR branches, in addition to automatically building master and development.

The behavior I’m seeing is that sometimes the PRs will report only the issues within the PR, and sometimes the PRs will report every single issue that exists in the master branch (regardless of which branch is the actual base). This will vary over the course of the day - sometimes it’ll report 3 issues in a PR, and after a single push to that branch the subsequent build will report 1400 issues - many in files that were totally untouched.

What is going on here? I can’t see any appreciable difference between the runs that work and the runs that don’t.

I am building +:refs/pull/(*)/head and using the latest version of the SonarScanner dotnet global tool and the latest version of SonarQube (updated yesterday).


SonarQube - Analyse Pull Request - Changed Files Only
(G Ann Campbell) #2

Hi,

What’s your SCM, and what version of your SCM support plugin are you running? (SQ version wouldn’t hurt either.)

Also, could you share your analysis command and the debug logs of an ‘all’ analysis?

 
Ann


(Melissa Benua) #3

We’re using Git 1.6.0.1349 and SonarQube 7.4.0.18908.

My analysis command is:

dotnet sonarscanner begin /k:“myServer” /n:“myServer” /d:sonar.login="%sonar.key%" /d:sonar.host.url=“http://my-sonarqube-instance:9000” /d:sonar.cs.opencover.reportsPaths=“coverage/*.xml” /d:sonar.pullrequest.base="$base" /d:sonar.pullrequest.key="$number" /d:sonar.pullrequest.branch="$branch"

dotnet build mysolution.sln

dotnet sonarscanner end /d:sonar.login="%sonar.key%"

Where $base is either ‘development’ or ‘master’, $number is the PR number like ‘123’ and $branch is like ‘feature/mycode’.

I run dotnet tool install --global dotnet-sonarscanner in a previous build step, to ensure that we always have the latest version of the dotnet global tool installed. We have ephemeral build machines, so it works out.

I don’t think I can give you the full raw debug logs, but if there’s specific things you want to look for I am happy to go and carve them out and report.


(G Ann Campbell) #4

Hi,

I was actually hoping for the version of your SonarQube Git plugin, found in Administration > Marketplace. The most recent versions (1.5+) include better detection of what’s new in a PR. Those improvements were shipped with 7.4, so unless you explicitly downgraded (you didn’t, did you?) then I guess we can assume you’re on a recent version.

Either way, an old version of the Git SCM plugin woudln’t explain why you sometimes get all issues. If it were about detecting what’s new in the PR I’d expect only a few issues to come and go.

That’s why I asked for analysis logs. I’m afraid I can’t tell you ahead of time what I’m looking for. But feel free to redact paths.

 
Ann


(Melissa Benua) #5

The Git plugin version from the marketplace is exactly what I gave you:

But yes, it’s the version that came bundled with the latest version of SonarQube.

I’ve implemented a workaround where I am now passing in the source-includes for only the files that have changed in the PR, so it’s not quite as clear anymore which PRs are buggy and which aren’t. I’ll grab some of the old logs, though, and see what I can send you.


(G Ann Campbell) #6

Sorry. I was looking at the wrong thing. Thanks for clarifying.