Examples showing defaults per project that can be overridden?

Hi I’m trying to locate an example where the project has a default sonar properties file which can be added to source control and then another sonar properties file that a developer can then override the default settings.

Is this possible with sonarqube?

Hi,

Welcome to the community!

If your properties file is checked in to the project, why wouldn’t the developer just modify it?

If you want to temporarily override some settings, then you can easily do that on the command line with the -D flag, e.g. -Dsonar.projectVersion=foo.

 
HTH,
Ann

Well, because adding usernames and passwords to source control is bad practice and is a security risk. SonarQube even highlights this itself when doing it’s analysis. Also checking files into source control only for developers to change the file is not the most idea way of solving this. This should be part of the developers environment, not the application implementation code.

The reason I wish to split them is because I would like everything except the login and password to be checked into source control, while the developer has a properties file with login and password.

I don’t expect my developers to type -Dsonar.projectVersion=foo every time they run SonarQube, that would be rather silly.

Is there no way for a developer to have his own properties file which would override a default file?

Hi,

And here I disagree with you. Developers should not be running analysis. Your CI system should, and the necessary credentials should be part of its environment. Ideally you’re going to create a technical user with absolute minimum privs, generate a token, and store that in your CI for analysis.

 
HTH,
Ann

You say this is a CI task. So how do developers get instant feedback when developing? Or at least check their code against SonarQube before it runs in the CI?

Having this checked only in the CI is a major waste of time. Developers should be able to run these analysis locally before pushing to the CI.

Hi,

I was afraid the point of this was getting feedback to developers. So first, you shouldn’t be analyzing in SonarQube code that hasn’t been checked in. If you and I are working on different features and we both want a pre-commit check at approximately the same time then we’re in a last-saved-wins situation … and ultimately no one wins.

That aside, it shouldn’t take any longer for the CI to run the analysis than it does for the developer.

What should be happening is a combination of SonarLint usage - in connected mode it will apply the same profile as is applied by SonarQube analysis - and perhaps PR decoration (available starting in Developer Edition($)).

 
HTH,
Ann

I see, that makes more sense with SonarLint now. So you run that locally and the analysis in the CI, both use the same rules on the SonarQube server. This was never clear in the documentation so thank you. Yes we have the PR decoration in place and is working.

Regarding your comment that it doesn’t take much longer, it does. The developer has to cleanup the local repo, commit or do an amend (depending on git strategy), push, wait (and for us we have a limited amount of runners in our CI so we can’t always check immediately, this is why I stress things should be done locally), then refresh the website, take a look. That does take longer, and doing that for every small little error you need to fix becomes a major time sink in development.

Regarding the comment of the win-win situation, if both are on different branches shouldn’t they be posted to results in different “branches” on the SonarQube server?

Hi,

If both are on different branches and running their analysis as different branches then you’re right; they’re not facing a race condition. I try not to assume folks have access to commercial features.

How are they passing the branch parameters in their local branch analyses?

 
Ann