PR Analysis Results Inconsistent - results from master branch sometimes included

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).


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?


We’re using Git and SonarQube

My analysis command is:

dotnet sonarscanner begin /k:“myServer” /n:“myServer” /d:sonar.login=“%sonar.key%” /“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.


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.


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.

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

I was scanning through the log today, and spotted this as a part of the project scan:

|[21:47:09] :| [Step 8/9] INFO: Project key: server|
|[21:47:09] :| [Step 8/9] INFO: Project base dir: /opt/teamcity/work/eea579053c825dc8|
|[21:47:09] :| [Step 8/9] INFO: Pull request 8900 for merge into development from feature/myfeature|
|[21:47:09] :| [Step 8/9] INFO: -------------  Scan MP.Endpoints|
|[21:47:10] :| [Step 8/9] INFO: Base dir: /opt/teamcity/work/eea579053c825dc8/src/MP.Endpoints|
|[21:47:10] :| [Step 8/9] INFO: Working dir: /opt/teamcity/work/eea579053c825dc8/.sonarqube/out/.sonar/mod177|
|[21:47:10] :| [Step 8/9] INFO: Source paths: Download.cs, ValidateSchema.cs, appsettings.json,,|
|[21:47:10] :| [Step 8/9] INFO: Source encoding: UTF-8, default locale: en_US|
|[21:47:10] :| [Step 8/9] INFO: SCM collecting changed files in the branch|
|[21:47:10] :| [Step 8/9] WARNING: WARN: Could not find ref: development in refs/heads or refs/remotes/origin|
|[21:47:10] :| [Step 8/9] INFO: SCM collecting changed files in the branch (done) | time=58ms|
|[21:47:10] :| [Step 8/9] INFO: Load server rules|
|[21:47:10] :| [Step 8/9] INFO: Load server rules (done) | time=167ms|
|[21:47:10] :| [Step 8/9] WARNING: WARN: Property 'sonar.abap.file.suffixes' is not declared as multi-values/property set but was read using 'getStringArray' method. The SonarQube plugin declaring this property should be updated.|
|[21:47:10] :| [Step 8/9] INFO: Index files|
|[21:47:10] :| [Step 8/9] INFO: Included sources: |
|[21:47:10] :| [Step 8/9] INFO:   **/Controllers/HealthController.cs|
|[21:47:10] :| [Step 8/9] INFO: Excluded sources: |
|[21:47:10] :| [Step 8/9] INFO:   **/lib/**|
|[21:47:10] :| [Step 8/9] INFO: 0 files indexed|
|[21:47:10] :| [Step 8/9] INFO: 2 files ignored because of inclusion/exclusion patterns|
|[21:47:11] :| [Step 8/9] INFO: Sensor SonarJavaXmlFileSensor [java]|
|[21:47:11] :| [Step 8/9] INFO: Sensor SonarJavaXmlFileSensor [java] (done) | time=1ms|
|[21:47:11] :| [Step 8/9] INFO: Sensor JaCoCo XML Report Importer [jacoco]|
|[21:47:11] :| [Step 8/9] INFO: Sensor JaCoCo XML Report Importer [jacoco] (done) | time=1ms|

If you ignore the part where I’m micro-managing my includes and excludes as a part of this problem, I see WARNING: WARN: Could not find ref: development in refs/heads or refs/remotes/origin|. This is weird to me because at the start it seems to know it’s pulling from development, and in SonarQube itself when viewing the analysis it seems to know it’s based on development.


Is it possible to know what specifically SonarAnalyzer is running on git, because development is definitely in the ref/heads on that agent.

Hi Melissa,

SonarQube knows that your P/R is targeting development because it’s specified in the command line.
The problem is that during the analysis it can’t find that branch in the local git references.
Are you sure that the reference is available the agent? Sometimes, to avoid downloading all branches, agents only fetch the branch being built.
You could try calling git fetch --all before calling sonarscanner.

1 Like

I’ll give that a try. For future readers, to do that on TeamCity with agent checkout you need to set the configuration parameter teamcity.git.fetchAllHeads=true into your build configuration.


I think that’s the magic that fixed it! I’m seeing significantly better behavior now. I’ll keep an eye and make sure it’s respecting base branch in a few other instances, but looks much better overall.

Alright, thanks for letting us know!