Enabling SonarCloud in Az-DevOps pipeline cause dotnet unit test to be slow

[planbsim (Simon Planberger)]

I have a dotnet core unit test within an Azure DevOps pipeline that usually takes 1-2 minutes.

When I enable Sonarcloud, the run takes up to 4 times as long as without (around 8-9 minutes).

We included the Sonarcloud steps in our Az-DevOps as described by Sonarcloud. Also I browsed through the community entries for e.g. Enabling SonarQube analysis cause dotnet build to be very slow but i cannot figure out what causes this time.

We are also running some integration tests which are also heavily impacted from the included sonarcloud processing.

The sonarloud tasks are:

  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: 'Sonar Cloud'
      organization: 'xxxx'
      scannerMode: 'MSBuild'
      projectKey: 'xxxx'
      projectName: 'xxxx'
      extraProperties: |
        sonar.cs.opencover.reportsPaths=$(Agent.TempDirectory)/**/*.xml
        sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)/*.trx

   - task: SonarCloudAnalyze@1

   - task: SonarCloudPublish@1

The DotNetCoreCLI@2 task for the unit tests:

task: DotNetCoreCLI@2
    displayName: Run dotnet test
    inputs:
      publishTestResults: true
      testRunTitle: 'Unit-tests'
      command: 'test'
      projects: |
        **/*Tests.csproj
        !**/*E2E.Tests.csproj
      arguments: '--configuration $(buildConfiguration) --no-restore /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput=$(Agent.TempDirectory)/coverage/ /p:MergeWith=$(Agent.TempDirectory)/coverage/ --collect "Code coverage"'

Please find our logfiles attached logs.zip (1.1 MB) . A logfile for running the unit tests with and without sonarCloud. Build logfile dotnet build ... /v:d /p:reportanalyzer=true for the project with and without sonarcloud. Hopefully it helps to figured out what caused this time issue.

TIA, Simon

[Andrei_Epure]

Hi @planbsim

thanks for the well written, detailed topic.

The first thing is to make sure you do the build only once (you can read similar advice here and more recently here). If you build multiple times, the Roslyn analysis will run multiple times, and that’s not necessary. Using the --no-build parameter when calling dotnet test should avoid building again during test phase. See dotnet test command - .NET CLI | Microsoft Docs .

From the logs, I cannot see big outliers. One analysis takes 166 seconds, probably that project is bigger (see lines 16771-16778). For CollectionQuerySimplification we have a ticket to improve, you can see the perf improvements backlog we have.

If you only do the analysis once, during the build, and don’t do it again for unit test run and integration test run, you’ll save a lot of time. This is what we do in our pipeline.

[planbsim (Simon Planberger)]

Thanks for your advice

You are right, using the --no-build parameter correctly improve the build time many times over. I was not aware of the fact, that dotnet test is building again during test phase.

Kind regards, Simon