SonarQube does not exclude files that are auto generated during the 'dotnet build' process

SonarCloud
, ,
1

Template for a good new topic, formatted with Markdown:

  • ALM used - Azure DevOps
  • CI system used - Azure DevOps
  • Languages of the repository - C#
  • Steps to reproduce:

If a file is auto-generated during the ‘dotnet build’ process on the build agent (i.e. - a file that is not committed to source control. e.g - a file created using Roslyn Source Generators) then we have not found a way to exclude it using sonar.exclusions or sonar.issue.ignore.allfile settings (although these settings do work for files that are committed to source control).

However, the file is still subject to analysis and is falling foul of certain rules, which is blocking us.

The only way round this that we have found is to deactivate the rule that is causing issues to be raised. However, this is an interim solution and we would like to find a way to exclude the file from analysis.

1 Like
2

Hi,

Welcome to the community!

Generated files should be skipped by default. Per the docs there’s a setting to turn that off (and thus analyze generated files). Can you make sure it hasn’t been toggled? (Project → Administration → General Settings → C#)

Also from the docs:

The detection of generated code is based on the file name, special comments, and attributes. The currently recognized values are in GeneratedCodeRecognizer.cs

Can you check to see whether your generated files match the criteria?

 
Ann

3

Hi Ann

Thanks for the reply.

I can confirm that these settings work when SonarQube is deciding what to report upon in the portal. However, the nuance here is that I would like the ‘dotnet build’ task in our pipeline to fail if SonarQube finds any issues. I have configured the ‘dotnet build’ task to raise warnings as errors, so that developers are forced to deal with issues during the pull request process, rather than as a retrospective exercise to act upon the report published to the SonarQube portal.

It seems that exclusions work fine when SonarQube is deciding what to publish in the final report. But, they don’t seem to work when the actual scan is done within the ‘dotnet build’ task. To put it another way, I want to stop SonarQube scanning certain files at all, not just stop it filtering out issues with files when publishing the final report.

Here is how SonarQube is normally set up in an Azure DevOps build pipeline:

  • task: SonarQubePrepare@4
    displayName: ‘Prepare the SonarQube analysis’
    inputs:
    SonarQube: ‘sonarqube’
    scannerMode: ‘MSBuild’
    projectKey: ‘key’
    projectName: ‘name’
    projectVersion: ‘version’

  • task: DotNetCoreCLI@2
    displayName: DotNet Build - Projects (no warnings as errors)
    inputs:
    command: build
    projects: ‘***.csproj’
    arguments: “–configuration ${{parameters.buildConfiguration}} --no-restore”

  • task: SonarQubeAnalyze@4
    displayName: ‘Complete the SonarQube analysis’

  • task: SonarQubePublish@5
    displayName: ‘Publish Quality Gate Result’

When I run this yaml with exclusions set, I can see warnings in the build output related to excluded files but, in the final report published to the portal, excluded files are not reported upon.

I have tweaked this as so:

  • task: DotNetCoreCLI@2
    displayName: DotNet Build - Projects (raise warnings as errors)
    inputs:
    command: build
    projects: ‘***.csproj’
    arguments: “–configuration ${{parameters.buildConfiguration}} --no-restore -warnaserror”

When I run this yaml, the warnings related to excluded files become errors, and the build fails. I want files to be ignored at this point, not just during the report publishing step.

1 Like
4

Hi,

Thanks for the details. I think this needs more expert attention…

 
Ann

6

Hi @monkeytennis, thanks a lot for your feedback.

If I understood correctly, the problem is that the filter is applied too late in the process and the excluded files are filtered out only during the end step, before the result is published to the server (and after the actual analysis was done).

This was a design decision that is not optimal due to multiple reasons (unexpected behavior, as you already noticed and also not optimal in terms of performance), that we reconsider and want to fix in the future. We will start with implementing it in the IDE (SonarLint) and then in the scanner (Azure DevOps as well) but this will take some time.

As a work around, could you please try adding a filter using .editorconfig files? I know that the settings can be very granular, allowing to disable a rule for a particular pattern of file names but I did not use this myself. It’s not something we usually recommend. See: Analyzer configuration - Visual Studio (Windows) | Microsoft Learn