Problem: File can't be indexed twice

[rsecuritas]

SonarQube:

• Enterprise Edition
• Version 9.3 (build 51899)

SonarQube (AzureDevops Extension) :

• Version 5.3.1

SonarScanner for MSBuild 5.4.1

I am trying to specify “sonar.sources” and “sonar.tests” in order to get a better sonarqube performance but I get this error:

##[error]File Wke.Partners.Crosscutting/Contracts/IConfigurationRestServices.cs can't be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files

I understand this error but I don t know how can I fix it without remove this two properties of the analysis parameters.

Both folders are separated in my folder project:

So:

sonar.exclusions=Documentation/**, Database/**

sonar.sources=Wke.Partners.Crosscutting, Wke.Partners.Data, Wke.Partners.Api

sonar.tests=Wke.Partners.Tests

But then I found that in logs:

Why files are indexing again in module ‘es_wke_OERP_partners_api’?

(this module is just my project_key/project_name)

In autodetection mode, i.e. commenting parameters, scan didn’t index files again in module ‘es_wke_OERP_partners_api’:

Did I miss an additional parameter?

Finally, this approach is a good practice to gain performance?

Thanks in advance,

BR

[ganncamp (G Ann Campbell)]

Hi,

Specifying one parameter doesn’t mean you have to specify them all. What happens if you retain sonar.exclusions but comment out sonar.sources and sonar.tests?

 
Ann

[rsecuritas]

Hi Ann,

If I comment the parameters sonar.sources and sonar.tests it works fine.

So, I don’t understand well when I have to use them because any test I did with any of these arguments gave me the indexing problems. Instead of these parameters, would you recommend me to use sonar.exclusions and sonar.inclusions? Or just use one of them for avoid indexing problems?

How I say before, it’s important for me understand well how/what scanner are going to index in order to gain performance.

Thanks!
BR

[ganncamp (G Ann Campbell)]

Hi,

These are fair questions and I fully appreciate the need to understand. The answers vary depending on which scanner you’re using. Three of the scanners sit on top of deeply integrated build systems: SonarScanner for .NET, SonarScanner for Maven, & SonarScanner for Gradle. For these three the build system knows pretty much everything about your project, so the scanner just harvests that data to do its job. That’s why it worked fine for you when you stopped overriding the default sonar.scanner and sonar.tests values provided by the build system.

On top of that, you used sonar.exclusions to tune that sources value to omit some source files the build knows about but that you don’t want analyzed. There’s a decent overview of it all in the docs.

 
HTH,
Ann

[duncanp (Duncan Pocklington)]

FYI we’ve created a documentation ticket for the SonarScanner for .NET to document how sonar.sources and sonar.tests should be used: MSBUILD-#1210.

In the meantime, the general advice is don’t set them explicitly.