- Enterprise Edition
- Version 9.3 (build 51899)
SonarQube (AzureDevops Extension) :
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:
sonar.sources=Wke.Partners.Crosscutting, Wke.Partners.Data, Wke.Partners.Api
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,
Specifying one parameter doesn’t mean you have to specify them all. What happens if you retain
sonar.exclusions but comment out
If I comment the parameters
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.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.
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.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.
FYI we’ve created a documentation ticket for the SonarScanner for .NET to document how
sonar.tests should be used: MSBUILD-#1210.
In the meantime, the general advice is don’t set them explicitly.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.