New Code always 0 for PRs – Issues detected only after PR is merged in Azure DevOps

:puzzle_piece: Problem Summary

In our Azure DevOps + SonarQube setup, SonarQube is not reporting any New Code or issues during pull request (PR) analysis. This causes all PRs to show:

  • :white_check_mark: “Quality Gate Passed” (due to 0 new lines/issues)
  • :chart_decreasing: “0 New Lines” in PR analysis
  • :prohibited: No detection of violations like TODOs, even when clearly added in the PR

However, once the PR is merged and the target branch pipeline runs, SonarQube then detects the new code and flags all the issues that should have been caught in the PR itself.


:magnifying_glass_tilted_left: Observations

  1. SonarQube does analyze PR builds successfully. Logs show ANALYSIS SUCCESSFUL with proper pullrequest.key, branch, and base values.
  2. New Code = 0 lines on every PR, despite real changes.
  3. After merge, the same violations are detected correctly in the branch scan.
  4. PR decoration doesn’t always show, even though it works fine for other similar projects.
  5. We see warnings like:
  • Missing blame information for xxx files
  • File 'xyz.cs' was detected as changed but without having changed lines

:wrench: What I’ve Tried

  • Using fetchDepth: 0 and explicitly fetching the PR target branch
  • Ensuring correct sonar.pullrequest.* parameters are passed
  • Persisting credentials and cleaning workspace
  • Compared with a working project that has nearly identical setup
  • Verified ALM integration in SonarQube is configured correctly

:sos_button: Request for Help

  1. Why is “New Code” always zero in our PRs—even with obvious code changes?
  2. What might be causing blame or diff to fail silently in SonarQube analysis?
  3. Are there additional Git or SonarQube configuration steps we’re missing for PR diff to work?

:building_construction: Pipeline Snippet (Simplified)

yaml

  • task: SonarQubePrepare@7
    displayName: ‘Prepare analysis on SonarQube’
    inputs:
    SonarQube: ‘SonarQube’
    scannerMode: ‘dotnet’
    projectKey: ‘myProjectKey’
    projectName: ‘myprojectNameAsInSonarQube’
    extraProperties: ‘sonar.scm.exclusions.disabled=true’

  • task: DotNetCoreCLI@2
    displayName: ‘Build Solution’
    inputs:
    command: ‘build’
    projects: ‘$(solution)’
    arguments: ‘–configuration $(buildConfiguration)’

  • task: DotNetCoreCLI@2
    displayName: ‘Run Tests’
    inputs:
    command: ‘test’
    projects: ‘**/*Test.csproj’
    arguments: ‘–configuration $(buildConfiguration) --no-build --collect “Code Coverage”’

  • task: SonarQubeAnalyze@7
    displayName: ‘Run Code Analysis’
    inputs:
    jdkversion: ‘JAVA_HOME’

  • task: SonarQubePublish@7
    displayName: ‘Publish Quality Gate Result’
    inputs:
    pollingTimeoutSec: ‘300’

Hi,

As I believe you suspect, this is your problem:

Excellent. Now make sure the prerequisites are in place. Given that you’ve already ticked the fetchDepth box, I suspect that’s the problem.

 
HTH,
Ann

Hi
I see all the prerequisites as per the link are in place. Still I am not seeing PR decorated. I also see the PR analysis on sonarqube dashboard having 0 issues, there should be many for this test PR.

is there something specific i should verify?

Hi,

Decoration is a different issue that “New Code always 0”. Let’s stick to that.

First, what shows up on the Measures tab?

Second, can you share you analysis log?

Share the Scanner for .NET verbose logs

  • Add /d:"sonar.verbose=true" to the…
    • SonarScanner.MSBuild.exe or dotnet sonarscanner begin command to get more detailed logs
      • For example: SonarScanner.MSBuild.exe begin /k:"MyProject" /d:"sonar.verbose=true"
    • “SonarQubePrepare” or “SonarCloudPrepare” task’s extraProperties argument if you are using Azure DevOps
      • For example:
        - task: SonarCloudPrepare@3
            inputs:
              SonarCloud: 'sonarcloud'
              organization: 'foo'
              scannerMode: 'dotnet'
              projectKey: 'foo_sonar-scanning-someconsoleapp'
              projectName: 'sonar-scanning-someconsoleapp'
              extraProperties: |
                sonar.verbose=true
        
  • The important logs are in the END step (i.e. SonarQubeAnalyze / SonarCloudAnalyze / “Run Code Analysis”)

Share the msbuild detailed logs

MsBuild.exe /t:Rebuild /v:d

or

dotnet build -v:d

 
Thx,
Ann

SonarQubeAnalyzeLog.txt (475.7 KB)

I am using devops pipelines. Task is SonarQubeAnalyze@7

Hi,

Thanks for the screenshot. I’d be curious what shows up in the Size portion further down on the left.

Thanks also for the log. I’ve excerpted some interesting lines below:

2025-05-06T16:26:31.7149250Z 16:26:31.714 INFO: Found manual configuration of branch/PR analysis. Skipping automatic configuration.

Ideally, you would let the integration pick this up automatically

2025-05-06T16:26:32.6987589Z 16:26:32.697 INFO: Pull request 6291 for merge into 5.22 from refs/heads/testSonarqube-2

Does this PR exist on the SCM server?

2025-05-06T16:26:33.3787585Z 16:26:33.378 DEBUG: 5 non excluded files in this Git repository
2025-05-06T16:26:33.3919049Z 16:26:33.391 DEBUG: File '[file path]' is excluded by the scm ignore settings.
// lots and lots of these^
...
2025-05-06T16:26:34.2475800Z 16:26:34.247 INFO: 2 languages detected in 2 preprocessed files
2025-05-06T16:26:34.2476517Z 16:26:34.247 INFO: 36 files ignored because of inclusion/exclusion patterns
2025-05-06T16:26:34.2477810Z 16:26:34.247 INFO: 779 files ignored because of scm ignore settings
...
2025-05-06T16:26:34.7912449Z 16:26:34.790 INFO: SCM collecting changed files in the branch
2025-05-06T16:26:34.8933628Z 16:26:34.892 INFO: Merge base sha1: 7406b3f3457986fad31b0e7c0b6710af45ff92ff
2025-05-06T16:26:34.9327130Z 16:26:34.932 INFO: SCM collecting changed files in the branch (done) | time=142ms
2025-05-06T16:26:34.9328719Z 16:26:34.932 DEBUG: SCM reported 27 files changed in the branch
...

A lot of files, all but 5 it seems, are excluded from analysis because they’re covered by the exclusions in your .gitignore file. So we have 5 files eligible to be analyzed, and 27 files changed in the branch. Is there any overlap between these two sets, I wonder? Because PR analysis only analyzes the files added or updated in the PR. So if those 27 changed files are among the “779 files ignored because of scm ignore settings” or the “36 files ignored because of inclusion/exclusion patterns” then it’s not surprising that your PR analysis shows up empty.

You should review both your .gitignore file and your inclusion/exclusion settings.

 
HTH,
Ann

to add some background. I had createdtestSonarqube-2 from recent release (5.23) and created PR to merge to main, which was on older release (5.22). This PR should have issues showing on sonarqube dashboard and PR being decorated. After I created this thread here, I noticed that main got updated with latest release changes, which is standard process here.
so i updated target branch of PR to merge to the older release branch (5.22).

after 5.23 merged into main, i see bunch of issues showing up in New Code portion:

I am hoping my test PR to show these issues.
I had updated my pipeline task to be:
task: SonarQubePrepare@7
displayName: ‘Prepare SonarQube analysis – PR’
condition: eq(variables[‘Build.Reason’], ‘PullRequest’)
inputs:
SonarQube: ‘SonarQube’
scannerMode: ‘dotnet’
projectKey: ‘projKey’
projectName: ‘projName’
extraProperties: |
sonar.scm.ignorePathSpecs=false
sonar.scm.provider=git
sonar.scm.exclusions.disabled=true

earlier it had
powershell: |
$full = “$(System.PullRequest.TargetBranch)”
$short = $full -replace “^refs/heads/”, “”
Write-Host “##vso[task.setvariable variable=TargetBranchName]$short”
displayName: ‘Determine short target branch name’

  • powershell: |
    Write-Host “Fetching remote branch origin/$env:TargetBranchName”
    git fetch --no-tags origin +refs/heads/$env:TargetBranchName:refs/remotes/origin/$env:TargetBranchName

    Write-Host “Creating local branch $env:TargetBranchName from origin/$env:TargetBranchName”
    git branch $env:TargetBranchName refs/remotes/origin/$env:TargetBranchName

    Write-Host “Local refs now:”
    git show-ref | Select-String “refs/heads/$env:TargetBranchName” | ForEach-Object { Write-Host $_ }
    displayName: ‘Fetch & create local target branch’
    condition: eq(variables[‘Build.Reason’], ‘PullRequest’)

  • task: SonarQubePrepare@7displayName: ‘Prepare SonarQube analysis – PR’condition: eq(variables[‘Build.Reason’], ‘PullRequest’)inputs:SonarQube: ‘SonarQube’scannerMode: ‘dotnet’projectKey: ‘projKey’projectName: ‘projName’dotnetScannerVersion: ‘8.0.3.99785’extraProperties: |# – PR metadata (only when Build.Reason == PullRequest)sonar.pullrequest.key=$(System.PullRequest.PullRequestId)sonar.pullrequest.branch=$(System.PullRequest.SourceBranch)sonar.pullrequest.base=$(TargetBranchName)sonar.verbose=truesonar.scm.ignorePathSpecs=falsesonar.scm.provider=gitsonar.scm.exclusions.disabled=trueto get rid of error i was getting Could not find ref 'refs/heads/main' in refs/heads, refs/remotes, refs/remotes/upstream or refs/remotes/origin
    

Hi,

I guess that was since you ran the analysis, the log of which you provided above?

Regarding this, I’m a bit confused:

Your screenshot shows that the New Code is “Since November 19, 2024”, with 8.6k New Issues in that period. Surely you’re not attributing all of that to your merged PR?

 
Ann

that’s another confusion I also have. the last merge to main happened on February 14,2025. Still it shows New Code: Since November 19, 2024.
My new code setup is:

Hi,

This means that you haven’t changed your sonar.projectVersion string since November.

 
HTH,
Ann

No. we didn’t update sonar.projectVersion for any project.
shouldn’t that mean that PR should show more issues than our expectations?

Hi,

PR analysis reports on what was added or changed in the PR. I’ll be honest and say I didn’t follow the whole 5.22 to 5.23 thing.

So let me say

  • Analysis has to have access to the full SCM metadata to understand what’s new
  • And the prerequisites need to be in place

 
HTH,
Ann

Apologies for the confusion. I am starting from 0 again trying to show the problem and hopefully solve it with your help.

5.22,5.23,5.24 are our release branches that developers merge their PRs into. Pipeline, including sonarqube tasks, runs every time a new release branch is created, PR is created/updated and when PR is merged.
We created 5.24 from 5.23 branch. This triggered a pipeline run for this project.
We had few PRs merge into 5.24 branch yesterday adding bunch of new code. I see on sonarqube dashboard that 5.24 has bunch of issues on the new code.


Now I created a new branch from latest 5.24 and named it test-5.24. Then I created a PR from test-5.24 to merge into 5.23. This triggered a pipeline run. I expected to see the issues on New Code of 5.24 to show in this PR, also decorating the PR. But it shows 0 new lines of code with 0 issues

Attached is analysis log of this PR and also the content of yaml used in the pipeline
SonarQubeAnalyzeLog20250507.8.txt (72.9 KB)
azure-pipelines.txt (2.1 KB)

Hopefully I am correct in my expectation that PR merging test-5.24 into 5.23 should show the issues which are showing on new code of 5.24. I verified few issues shown, they are on actual new code since 5.24 was branched off from 5.23.

Hi,

Can you move that sonar.verbose=true to the prepare step and provide the full log, starting from the prepare step?

 
Thx,
Ann

SonarQubePrepare20250508.2.txt (11.5 KB)
SonarQubeAnalyzeLog20250508.2.txt (2.8 MB)
2025-05-08T18:01:14.3967523Z ##[section]Starting: Publish Quality Gate Result
2025-05-08T18:01:14.3974278Z ==============================================================================
2025-05-08T18:01:14.3974391Z Task : Publish Quality Gate Result
2025-05-08T18:01:14.3974446Z Description : Publish SonarQube Server’s Quality Gate result on the Azure DevOps build result, to be used after the actual analysis.
2025-05-08T18:01:14.3974553Z Version : 7.3.0
2025-05-08T18:01:14.3974600Z Author : sonarsource
2025-05-08T18:01:14.3974657Z Help : More Information
2025-05-08T18:01:14.3974766Z ==============================================================================
2025-05-08T18:01:14.8853236Z [INFO] SonarQube Server: Server version: 2025.2.0.105476
2025-05-08T18:01:52.3792231Z [INFO] SonarQube Server: Task 547ebd77-d446-4b7b-8007-d584409c0a10 completed
2025-05-08T18:01:52.3792906Z [INFO] SonarQube Server: Analysis succeeded with warning: Multi-Language analysis is enabled. If this was not intended and you have issues such as hitting your LOC limit or analyzing unwanted files, please set “/d:sonar.scanner.scanAll=false” in the begin step.
2025-05-08T18:01:52.4878128Z [INFO] SonarQube Server: Overall Quality Gate status: ok
2025-05-08T18:01:52.9354639Z ##[section]Finishing: Publish Quality Gate Result

Hi,

Thanks for the logs. For C# the rules are actually run during the build. I was hoping to see the build log (so the log in between the two you provided) to see evidence that the rules are running. Or not.

Can you upload that one as well?

 
Thx,
Ann

BuildSolution20250508.2.txt (5.6 MB)

Hi,

Thanks for that log. I immediately see clear evidence of the rules running.

Warning S125: Remove this commented out code. (https://rules.sonarsource.com/csharp/RSPEC-125)

And this wasn’t why I requested the build log, but I did spot something else in it that may be relevant:

2025-05-08T17:58:20.9845201Z ==============================================================================
2025-05-08T17:58:20.9845312Z Task         : .NET Core
2025-05-08T17:58:20.9845361Z Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2025-05-08T17:58:20.9845452Z Version      : 2.256.3
2025-05-08T17:58:20.9845500Z Author       : Microsoft Corporation
2025-05-08T17:58:20.9845563Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2025-05-08T17:58:20.9845636Z ==============================================================================
2025-05-08T17:58:21.5221879Z [command]C:\Windows\system32\chcp.com 65001
2025-05-08T17:58:21.5613487Z Active code page: 65001
2025-05-08T17:58:21.5748140Z Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.

It seems that you’re using a very old version of .NET Core, which per the docs, isn’t supported:

Can you bump up your version and see if this is still a problem?

 
Thx,
Ann

that’s standard message in azure devops pipelines as far as i can tell. All our projects are on .net8. but i still see this message on build tasks for all of them, even the ones we started from scratch using .net8

Hi,

Why does the header say

 
Thx,
Ann