Do SonarSource prefer the use of Web UI for project configuration? If yes, why?

SonarQube Server / Community Build
1

I use SonarQube 8.3 Developer edition.

I am sure that many of my fellow peers use configuration files all the time. They are useful because they can be checked in to source control for audit-ability, they can be templated, they can live along side the project that they are configuring etc.

Sonar has a file called sonar-project.properties that allows you to configure a projectName and a select few other values.

Often when SonarSource releases a new feature I hope to see a config parameter for it but nearly always the only way to configure it is to use the Web UI. This is painful for me because only a small subset of users have project admin rights and even if I gave every developer admin rights i would then need to train them all on how to enable certain features and functionality and hope they don’t misconfigure other things.

If you do a quick search of the Community the message from SonarSource is pretty clear - How to set sonar.issue.ignore.block in sonar-project.properties - #5 by janos

Hi @dschnare,

We recommend users to use the UI to configure this, for best experience. Consider the configuration via sonar-project.properties as an undocumented hack, not official supported that may or may not work reliably, use at your own risk.

Cheers,
Janos

Some examples of things I would like to configure with sonar-project.properties:

  1. PR decoration. For every new project I have to go to the UI → Project Settings → General → PR Decoration → Choose config from dropdown and save
  2. Configuring the New Code period (see Why cant Code Period start from my main branch when scanning a feature branch? - #6 by Rebse)

In summary, my question is do SonarSource favour the use of Web UI in order to configure projects? If yes, why - considering the advantages I listed above regarding file based configuration for the project? If no, how would you recommend solving for my two problems above?

1 Like
2

Hi,

We favor using the UI for 2 reasons:

  1. for things like sonar.issue.ignore.block it’s very difficult to get right from the properties file because it’s actually a multi-value property set. I speak from experience when I say that after you’ve talked about the 5th person through that (at tedious, painful length) you say “just use the UI”.
  2. some things should be set and left. Quality Profile is a good example of this. The vast majority of projects - if not all - should be using the default profile -> nothing to configure at all. For the few exceptions… making a manual change can be an exceptional operation.

The same is generally true for New Code Period. If you’re one of those folks who’s using the ‘Specific analysis’ method of setting the New Code period, well we designed this feature to be invoked via web service with the assumption that you’d include it in your release automation to set the analysis of the released build as the baseline for the new New Code Period. Again, nothing to manually configure here. For all the other values, you should be able to set it and forget it.

For your specific example about PR decoration, there’s actually a different reason: scope. The values you pass in to analysis are out of scope by the time PR decoration happens. (We do not update project settings from analysis parameter values; that way lies madness.)

 
HTH,
Ann