SQ reports warnings for excluded files in DevOps pipeline

SonarQube Server / Community Build
, ,
1

SonarQube 10.6.0 deployed via Docker

In my DevOps (on-prem) pipeline I’m trying to build my project. Said project contains some auto-generated code that should be excluded from SQ analysis. However, the build process throws a lot of SQ-related warnings related to this code during the build step. Specifically Entity Framework migration code is being flagged with S1192.

I’ve added a sonar-project.properties file in the root folder with the following:

sonar.projectKey=<redacted>
sonar.projectName=<redacted>

# Define root directory for sources and tests
sonar.sources=/src/
sonar.tests=/tst/

# Exclude from source scope
sonar.exclusions=src/<redacted>.Base/**/*.cs, src/<redacted>/Migrations/*.cs

The relevant pipeline steps are:

- task: SonarQubePrepare@6
  displayName: 'Prepare SonarQube'
  inputs:
    SonarQube: 'SonarQube'
    projectKey: '<redacted>'
    configFile: sonar-project.properties
    configMode: file
- task: DotNetCoreCLI@2
  displayName: Build project
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: --configuration $(BuildConfiguration) -p:AssemblyVersion=$(GitVersion.AssemblySemVer) -p:Version=$(GitVersion.AssemblySemVer) --no-restore

An example of the warnings thrown during the build stage:

##[warning]src\<redacted>\Migrations\20230523212707_Init.cs(18,51): Warning S1192: Define a constant instead of using this literal 'uniqueidentifier' 9 times. (https://rules.sonarsource.com/csharp/RSPEC-1192)
C:\azp\agent\_work\1\s\src\<redacted>\Migrations\20230523212707_Init.cs(18,51): warning S1192: Define a constant instead of using this literal 'uniqueidentifier' 9 times. (https://rules.sonarsource.com/csharp/RSPEC-1192) [C:\azp\agent\_work\1\s\src\<redacted>\<redacted>.csproj]
##[warning]src\<redacted>\Migrations\20230523212707_Init.cs(19,55): Warning S1192: Define a constant instead of using this literal 'nvarchar(max)' 62 times. (https://rules.sonarsource.com/csharp/RSPEC-1192)
C:\azp\agent\_work\1\s\src\<redacted>\Migrations\20230523212707_Init.cs(19,55): warning S1192: Define a constant instead of using this literal 'nvarchar(max)' 62 times. (https://rules.sonarsource.com/csharp/RSPEC-1192) [C:\azp\agent\_work\1\s\src\<redacted>\<redacted>.csproj]

Any idea what I need to do to get SQ to ignore the auto-generated code during the build phase?

2

Hey there. Due to some particularities of C# analysis, all files get analyzed (during the build of your project) and then files are filtered out based on your exclusions during the SonarQubeAnalyze step.

However, assuming your exclusions are configured correctly, they won’t appear on SonarQube.

However – also in mind that sonar-project.properties is not used when using the SonarScanner for .NET. Your task should exclude configFile and configMode and add scannerMode, like this:

- task: SonarQubePrepare@6
  inputs:
    SonarQube: 'YourSonarqubeServerEndpoint'
    projectKey: 'YourprojectKey'
    scannerMode: 'MSBuild'

You can also add extra properties, like your exclusions

extraProperties:  |
  "sonar.exclusions=src/<redacted>.Base/**/*.cs, src/<redacted>/Migrations/*.cs"
3

So… just to confirm - there’s no way to get rid of the SQ warnings during compilation?

The reason I ask is because this “dirties up” the build logs. I’m using a fairly simple example (i.e. a project which doesn’t have many warnings in total), but we have a few that are… well, rather vast in terms of warning counts - and it’d be nice to know which of those are things to be worried about and which are leftovers such as auto-generated code getting flagged.

4

I dug a little deeper and found this advice from @Pavel_Mikula

you can use .editorconfig to disable rules on that specific path as part of Roslyn configuration. Or you can extract those generated files into a separate project and exclude it from analysis with SonarQubeExclude.

So if all your generated code is in the same project, maybe SonarQubeExclude is just the ticket!

5

Hi,

One more thing to check is your Analyze generated code settings under your Project Settings / Languages / C#.

Is it turned on or off?

In case it is off, a question to look at is why those autogenerated files were not detected as autogenerated. What comments and attributes are used to detect autogenerated files is visible here:

Can you share the leading comment of your files with us?

6

I don’t think I can blame that part. EF doesn’t mark the migration files with any typical “autogenerated” markers. Supposedly it’s because these files are made to be edited by hand if need be. They are, in essence, “semi-autogenerated”, if one could call them that.

Which is why I was trying to manually exclude them in the first place…

7

I think I found a solution that… sort of works? I can change the name of the migration files to use the suffix .g.cs. It definitely stops SQ from throwing warnings over the code during build at the cost of slight naming weirdness (at least in this case)…

1 Like
8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.