Speed up SonarCloud pipeline for PR validation

[Tomas_Pazourek (Tomáš Pažourek)]

Hello, we’re trying to use SonarCloud on a very large solution (over 100 projects) and integrate it into Azure Pipelines to integrate with PRs in Azure DevOps.

Without SonarCloud, the build of the solution (MSBuild /t:Build) is ~8 minutes. But when we add SonarCloud (call the “prepare” pipeline step), the build gets significantly slower to ~24 minutes. That’s because of all the additional analysis that runs as part of the compilation step.

Since we’re using this inside validation builds in PRs, only the code issues found in the changed lines are reported into the PR as comments. But still the entire solution is analyzed and slowed down, not just the changed parts.

Is there some way to make this faster? If the PR validation builds take too long, we cannot use them as it degrades the developer experience too much.

[Colin]

Here is a great place to start.

The Sonar guide for investigating the performance of .NET analysis

This guide is intended to help SonarQube and SonarCloud users investigate .NET analysis performance issues. This effort can lead to: self-diagnose and fix a performance issue gather information to open a well-defined topic on this community forum help SonarSource improve the performance of the products Before discussing how to investigate performance issues, you should first understand the different steps of the analysis. Introduction to the SonarSource .NET static analysis State-of-the-a…

[Andrei_Epure]

@Tomas_Pazourek

Is there some way to make this faster?

Hi, from the guide Colin mentioned, I would recommend to start by adding more CPUs to your build machines:

@Andrei_Epure

Increase build machine resources

Static code analysis is resource intensive. By increasing the number of CPUs on your build machines, MSBuild will run concurrently. When analysing various open source projects with Sonar, we have seen significant improvements when increasing the CPU count.

For example, the tables below show that increasing from 4 CPUs to 8 CPUs can reduce the analysis time by almost 40%.

This works in practice:

@Mibe

We did made improvements already for our builds. We doubled our CPU’s for the build machines, I guess those were the biggest bottleneck for now. The time reduced from 40 minutes to 15 minutes.

Also, make sure you don’t run the analysis twice (during build and test execution).

@Andrei_Epure

Make sure you do not run the analysis twice

[Tomas_Pazourek (Tomáš Pažourek)]

Thank you. This will be useful if I want to get into depth on how to optimize the details.

Since SonarCloud only reports issues for the changed code, is it possible that it would only run analysis on the changed code? Is there some way of achieving that?

[Colin]

We are gradually working towards being able to limit the files that are analyzed in the context of PR analyses (we’ve already done this in SonarQube for languages that don’t require cross-file analysis, and implemented server-side caches for Java and C/C++ which do cross-file analysis).

These changes will eventually make their way to SonarCloud – but still leaves a few languages (mostly our flagship languages, including C#) where this still isn’t possible. Additionally, analysis of C# is done in such as specific manner (using Roslyn analyzers executed at build-time) that I’m sure there will be some additional complexity (if it’s possible at all).

So right now, the only thing you can do is focus on the optimizations described by @Andrei_Epure and that are found in the performance guide.

And, this remains a topic on our radar.

[Tomas_Pazourek (Tomáš Pažourek)]

Thank you for taking time to explain, this is exactly the information I was looking for.