Admin improvements for SonarQube

SonarQube Server / Community Build
1

I guess there is a reason why I lobby against Sonarqube in every project I come to, this is just such a prime example. Instead of just implementing this very useful feature which brings at least some order in the mess what is called the project list, this is argued against since years. Well, one more item for my long “why no sonarqube” bucket.

That Sonarqube still has no way of defining parent project relations in multi-module / multi-product builds via analysis parameters is just another one. Or that there is still no way of defining a default branch by default that is not called “master” in the UI. Or that build stability is at risk when quality gates are used. Sonarqube was, is and probably always will be a management-blinding piece of smoke-and-mirrors software with little actual use for developers.

2

Hi @Thomas_Keller,

This is a new one on me. I invite you to create a new thread to explain this use case. We’d be interested to see it.

There is actually, and it’s been around for… about a year now? On the main Administration page:

Selection_1613

That’s a choice made by whomever constructed your pipeline. Extra steps are required to put your “build stability at risk when quality gates are used”. So you should talk to whomever it was that decided a build that doesn’t meet your own internal standards should be blocked.

 
Ann

3

Hi Ann,

thanks for coming back to me. So, sonar.projectCreation.mainBranchName was indeed new to me, I haven’t looked into more recent (~12 months) development of the sonarqube plugin. Nice to see that it is finally there.

Parent project…
This is a new one on me. I invite you to create a new thread to explain this use case. We’d be interested to see it.

Use case is pretty simple. I want my project structure be defined through analysis metadata. Each time I have to go to Sonarqube’s UI to do things manually, such as

  • moving projects under the correct parent project umbrella
  • assigning a set of new projects quality gates / quality profiles not based on used languages, but parent project (i.e. what the specific team decided upon)
  • manually removing projects that are no longer analyzed within a parent project, because they got renamed / removed

I loose time and also patience with Sonarqube. Sonarqube should allow me to define sensible defaults for all of this via parent projects.

That’s a choice made by whomever constructed your pipeline. Extra steps are required to put your “build stability at risk when quality gates are used”. So you should talk to whomever it was that decided a build that doesn’t meet your own internal standards should be blocked.

The issue is not that this is “decided” by somebody or that this can be questioned, the issue is how this concept of quality gates and quality rules is implemented in Sonarqube. See, as long as I use Sonarqube just as a fancy quality window into my applications, everything is fine. But when people see “oh, you can make your build break based on quality gates, cool” problems begin. Because then these configurations that are made in an external, unversioned system as Sonarqube suddenly make your build dependent on this very configuration. So if the team creates a release and moves on their development branch with changed settings (either new rules are introduced by a SQ update, rules severity are adapted, quality gates are adapted, whatever), then the Sonarqube analysis, when guarded with a quality gate, will likely break the hotfix release process.

You might say “well, then disable quality gates on release branches”, but then why have them anywhere enabled in the first place? I want all builds to break, when things are violated. And I accomplish this today, still, by including build-level tooling (Spotbugs, KtLint, Detekt, PMD, …) because there the configuration is versioned along with the code, just like in the “old days” of Sonarqube where Sonarqube was merely a frontend for local tool execution.

Thanks for listening,
Thomas.

4

As a follow-up, I can’t find sonar.projectCreation.mainBranchName here: Analysis parameters

This is however my go-to place to find (global) analysis parameters. Was this simply forgotten to be documented there or is there another place?

This might be the reason why I missed it in first place.

5

Hi Thomas,

I’ve split this off into a separate thread since it seems to be diverging a bit.

Am I correct in thinking this is about Portfolios? If so - and at the risk of aggravating you - I need to point out that Portfolios can be defined by regex or… project tag. (Yes, I know.)

To be clear, this would be an automated deletion of the whole project from SonarQube? Or just removing it from a portfolio?

You’re not the first to raise this kind of thing, but to be honest, there hasn’t been enough user interest previously to bubble this to the top. That said, we’ve reshuffled a little internally, and there might be fresh interest in this kind of thing.

To be clear, you’re citing versioning because you’d like

  • to be able to rollback to a previous iteration
  • change comments (the profile changelog does track who/when, just not why. And yes, there’s nothing for Quality Gates)
  • something else
  • all of the above?

I don’t mean this in the smartass way it’s going to read, but this is why we recommend testing the upgrade before running it in production - so you can anticipate the impacts and decide on the best timing.

No, I’m not going to say that. I understand the frustration of having things break seemingly at random, only to find out that new rules were added or rules got smarter. And at the same time… we honestly see it as a feature-not-a-bug when issues that weren’t previously found get raised before they can be put into production.

And on the third hand (:alien: :wink:), presumably a hotfix is a tiny change being made on a stable branch that previously passed all inspection. So I get that it’s maddening that you suddenly can’t deploy to fix broken production (that’s what a hotfix is, right?) because SonarQube is suddenly complaining about things that didn’t bother it yesterday.

I think it’s worth pointing out that Accepting (in 10.4) or Won’t-Fixing (10.3 & below) those “extra” issues will make your QG pass - although that probably doesn’t kick your pipeline back into gear. And I agree that a more nuanced approach overall would be nice. So I’m going to flag this for PM attention.

 
Ann

7

Hi again,

As a followup to your followup (we were typing at the same time, I think :smiley:)

The Analysis parameters page lists the settings that can only be set via analysis. Things that can be set in the UI or analysis are listed with their keys and description in the UI.

Why aren’t all settings listed in the docs? Because the list is loooong, and it can be appended by plugins. And doing so encourages people to set everything via properties even when doing so via the UI is far, far easier and cleaner. And people get confused, thinking they need to go down the list and set everything even when some sittings contradict or perhaps snarl each other up. And… I learned this one the hard way. :smiley:

 
HTH,
Ann

8

Well, then I guess it would be very helpful to have a searchable options page for each SQ instance. The configuration options are complex and numerous enough to satisfy this and people are used to this in their IDEs, e.g. look into the IntelliJ Settings dialog where you can full-text search for options. Or, have a “display all settings on single screen” option, so one can browser-search the page for things.

9

Hi,

That’s there, both at the global level:

Selection_1615

And at the project level:
Selection_1617

 
Ann

10

Ok, I see, my SQ version is too old. I’ll come back to you after I updated. Thanks for the support so far!

1 Like