We are using SonarQube version 10.5 with Enterprise license.
Here is a sample to explain what we want to achieve:
We have 24 separate Git repositories which are packed in 24 different Jenkins pipelines.
In our Jenkins pipelines, we are scanning via SonarQube.
As we are working on a general standardized way of working for different technologies, we followed the technology-agnostic way of working while scanning which is to use sonar.properties files.
This means that in all 24 repositories, we have copy pasted the same sonar properties with a few changes like name and key.
We have been wondering if it is possible to define a common sonar.properties file and reuse/import it in all 24 repositories. This will make it possible to maintain properties of all projects from one location, and decrease the possibility to make mistakes.
We have also seen that Applications might be useful for this use case but the documentation is very limited (Applications). I tried to create an Application on SonarQube, but that’s it. It is not clear how to use it with sonar.properties.
First of all I don’t think “applications” can help you achieve your goal.
It’s just a way to aggregate analyses.
Your desire to harmonize the configuration of quality analyses is an interesting approach. The choice to use the scanner and the sonar-properties file is a very good lead.
You also have the possibility to use the “General Settings” in the sonarqube server.
If you are looking for an “asCode” solution, the possibilities you will have will in my opinion depend on how you have harmonized your jenkins pipelines. Do you use the Jenkins shared libraries or another way to standardize the Jenkins pipeline?
In the case where you have shared the call to the scanner, one solution is to generate the sonar-project.properties file dynamically just before the call to the scanner. The file generation can
-include parameter calculations such as projectKey / projectName
-language identification to manage specific parameters
…
You can also check beforehand if the sonar-project.properties file does not already exist to allow an overload from sources. This way you offer flexibility to take into account evolutions of frameworks before “standardization” and not prohibit teams who wish to go further in the use of Sonarqube’s features.
I use this approach on thousands of repositories using shared librairies and a specific Docker image for Quality Analysis step.
My conclusion from your answer is that it is technically not possible to reuse/import other properties file for a more modular way of managing sonar configurations for my projects. We have to develop our own solution for this on Jenkins pipelines where we call Sonar scanner.
I still think that it is a nice use case and very useful for easy maintenance of multiple projects of a single product.
