Sonar 10.1 and Azure Devops - weak performance

  • Sonar: 10.1
  • License: Enterprise licence

Our project

  • C#, .NET 7
  • 966.000 LOC

After sonar integration into Azure Devops our pipelines started to process longer without any very positive trend. We would expect some incremental scans.

Our azure implementation:

Before build:

#Prepare Analysis Configuration task

  • task: SonarQubePrepare@5
    SonarQube: ‘SonarQubeProject’
    scannerMode: ‘MSBuild’
    projectKey: ‘xas-border_cihla_AYpfUTWWefsutADW31’
    displayName: SonarQube Prepare Analysis Configuration

After build:

#Run Code Analysis task

  • task: SonarQubeAnalyze@5
    displayName: SonarQube Code Analysis

Situation day by day:

Prior sonar (also writing sonar parts of builds so that it is consistent)

1.9. (1st of September)

Sonar prepare: 0m
Backend build: 7m16s
Sonar analyze: 0m

With sonar


Sonar prepare: 2s
Backend build: 25m46s
Sonar analyze: 5m49s


Sonar prepare: 2s
Backend build: 22m4s
Sonar analyze: 5m3s


Sonar removed
Sonar prepare: 0s
Backend build: 9m18s
Sonar analyze: 0s

So average time of build jumped from 8 minutes to 23 minutes and we additionally have to wait about 5 minutes because of Sonar analyze.

Is this normal or could there be any problem anywhere? We cannot have 30 mins more in build time.



Hi Roman,

Incremental analysis only kicks in for pull requests. Currently, branches get a full analysis each time.

With nearly 1million LOC, I’m not surprised analysis takes a while, and a pipeline increase of ~20min isn’t bad IMO.

That said, you’re on SonarQube 10.1 and I believe there were some (small) performance improvements in 10.2. Can you upgrade?



thanks for reply. Just for clarify.
Interesting “only for pull request”. Can we ever achieve this kick in our situation?

We have nightly AZ devops pipeline which builds (and analyses master branch)
When someone make code change, he

  1. make new branch out of master.
  2. commit changes to this branch
  3. make pull request (here is a kick? I do not think so because it is the first scan of that branch…?)
  4. he merges pull request

So am I right that we never get advantage of incremental analysis? Or ok sometimes pull request triggers build more times because of additional changes came based on for example code review so in this quite rare situation we get that kick :slight_smile: Right?



Hi Roman,

I believe the target branch needs to be analyzed, and then PR analysis should be incremental (only including files changed in the PR) automatically.