Azure Devops SonarCloudPrepare with csharpenterprise 10.13.0.120203 - possible regression/bug?

  • ALM: Azure DevOps
  • CI system: Azure DevOps

Version from Tuesday, works fine:
Processing plugin: csharpenterprise version 10.12.0.118525
Processing plugin: vbnetenterprise version 10.12.0.118525
Today:
Processing plugin: csharpenterprise version 10.13.0.120203
Processing plugin: vbnetenterprise version 10.13.0.120203

It takes 3x time on “dotnet build” step now.

- task: SonarCloudPrepare@2
  inputs:
    SonarCloud: 'SonarCloud'
    organization: 'xxxacmecorporationxxx'
    scannerMode: 'MSBuild'
    projectKey: '$(projectKey)'
    projectName: '$(projectName)'
1 Like

We noticed the same issue. Our VSBuild (MSBuild) step went from taking about 10 minutes to over 50 minutes, causing the whole job to time out.

Hi,

Thanks for these reports.

Could we get some verbose analysis logs so we can see where the time is going?

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

I’ll see what I can do. My ADO pipeline looks like this (truncated):


  - task: SonarCloudPrepare@3
    inputs:
      SonarQube: 'SonarCloud Analysis'
      organization: '<org>'
      scannerMode: 'dotnet'
      projectKey: '<key>'
      projectName: '<name>'
      extraProperties: |
        sonar.verbose=true

  - task: VSBuild@1
    enabled: true
    inputs:
      solution: '$(solution)'
      msbuildArgs: '/p:Configuration=Debug /p:Platform=x64 /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:SkipInvalidConfigurations=true /t:Build /p:RunOctoPack=true  /p:OctoPackPackageVersion=$(Build.BuildId)'
      platform: '$(buildPlatform)'
      configuration: '$(buildConfiguration)'

  # - task: VSTest@2 ...
  # - task: PublishTestResults@2 ...
  
  - task: SonarCloudAnalyze@3
  - task: SonarCloudPublish@3
    continueOnError: true
    inputs:
      pollingTimeoutSec: '300'

It times out when running the VSBuild@1 task, so it doesn’t reach SonarCloudAnalyze@3 and may not be able to get the logs you want.

For the MSBuild logs, is there any way to share them non-publicly?

Same thing. Running verbose mode pipeline right now.

Analyze step finished, let me know how to share the log privately

1 Like

Hello and thanks for the reports. We are in the process of rolling back the changes to mitigate the impact.

To analyze the root cause of this, it would be super helpful to have access to the build’s binlog.

Could you add the following (replace <path> with where you want the file to be created) to your build command and provide us the created file?

/p:reportanalyzer=true /bl:<path>\build.binlog

Thank you!

2 Likes

And if someone experiences this on a public project or is otherwise able to share the source code with us, this would be very helpful too.

For the binlog, is this something that you’d need from the CI build or would a local Visual Studio build work as well? I’m sure it’s possible to extract the generated file from the ADO pipeline run, but it would take some research on my end to figure it out unless you have a recipe.

1 Like

A local build would suffice. The bigger hurdle now is that we already rolled back the change, so you should not be able to reproduce the regression. I will look for a reproducer and then create a binlog myself.
If all fails, I might come back to you and ask you to run an analysis with a custom build of the analyzer, but I hopefully find a better way.

2 Likes

A new version of the .NET analyzer (10.14) was released to SonarQube Cloud. It mitigated the performance regression in our internal tests but please let me know if you encounter problems again.

1 Like

I can confirm 10.14 works great with our setup.

2 Likes