Reputation: 1056
It seems to me it is a good practice to have all build-related configuration or quality-related rules of a project defined inside the project itself (as human-readable configuration files). This has several advantages: any developer coming to the project can readily see what configuration it uses; human-readable configuration files are auto-documented ways of reproducing the configuration (e.g. in case a new server needs to be installed or switching to a different service); the configuration history gets stored in the same place as the rest of the history of the project.
But AFAIU the documentation of SonarQube is rather oriented towards using the SonarQube UI to change settings on a project. For example, I couldn’t find how to configure a different quality gate than default using a property file, rather it is suggested to configure it using the UI or using curl. This would make it non obvious to a foreign developer that a different quality gate is used on that project, it seems to me.
Upvotes: 2
Views: 511
Reputation: 4420
You are not missing anything and indeed some configuration like Quality Gate and Quality Profile can be configured only via server UI. Mostly because usually, you would like to share this configuration across the organization and different projects, so it is easier to centralize it on the server itself.
Project specific settings can be set by creating sonar-project.properties
file or setting the properties in maven or gradle build files. You can configure exclusions, coverage, test reports this way.
You can use web api to configure server programmatically, but doing so for every project is not the intended usage pattern and you might encounter some difficulties.
Upvotes: 3