We are running SonarQube Developer Edition 10.1 and I would like to set sonar.source and sonar.tests globally so that every project can benefit from this without having to configure single projects in their sonar-project.properties file.
Is there a way to do that in the UI?
Hey there.
It’s not possible to set these globally for projects. These properties are specifically designed to be configurable on a per-project basis to allow for the unique characteristics of each project.
There are also many project types that configure these automatically (Maven, Gradle, .NET) and should not be adjusted outside the defaults the build system configures.
Can you describe the projects in your organization and when the defaults don’t work as expected?
Our projects are usually structured like this
/ <-- all source code
/tests <-- all test code
so I’d like to get this globally configured as
sonar.source=.
sonat.tests=./tests
At the moment all the metrics are attributed to the “Main code” scope and I’d like to differentiate between “Main code” and “Test code” (see screenshot). For us, it would be inconvenient to edit the sonar-project.properties file for all our projects (60+) to get the scope correctly tracked.
I noticed that one can pass configuration parameters to the sonarscanner command line. Would they be merged with the ones from the sonar-project.properties file. This would be a more viable solution for us, since the sonarscanner docker image call is in a centralized piece of infrastructure code.
Hey there.
Yes, it can be passed as an analysis parameter to the command line! Take note that it will override any other place sonar.tests might be set (command line analysis parameters always take precedence)
Apparently
sonar.source=.
sonat.tests=./tests
is not supported, probably because of ./tests being inside ..
Indeed, given that project structure you’ll have to try this:
sonar.sources=.
sonar.tests=.
sonar.test.inclusions=tests/**/*
Thanks, I tested the configuration and it seems to work. However, the total issue count is much lower with the new configuration. From a quick check, it seems that it is not a problem with included files, rather some rules are not applied for test files.
Is this correct?
If so, can you point me to where in the rules definition it says if they are applied or not to test code?
Hey there.
Very few rules are applied to test files today (and mostly involve rules that are actually about writing tests). Applying more rules to test code is on our roadmap.
The data about which rules apply to test sources isn’t well structured – what language(s) are you analyzing?
I looked into our Python projects. We also have some Python+Javascript projects.
So, do you confirm that, by defining sonar.tests I should expect the issue total count to go down significantly?
Yes, compared to indexing as sonar.sources (some users choose to do this, by the way, if they feel all rules apply equally well to their test code).
Understood. So there’s no way to know which Python (and maybe Javascript) rules apply to source and not to tests?