Feature/added active_rules and inactive_rules to qualityprofile

[ff00ff2337]

Added active_rules and inactive_rules list to qualityprofile resource:

resource "sonarqube_qualityprofile" "main" {
    name     = "example"
    language = "js"
    is_default = false
    parent = "sonar way"
    active_rules = {
      "javascript:S126" = "CRITICAL",
    }
    inactive_rules = [
      "javascript:S6836",
      "javascript:S2870",
    ]
}

Both attributes have ForceNew: true, so rule activation/deactivation could lead to consistent results based on the default quality profile.

[freeranger]

Hi - see discussion here: https://github.com/jdamata/terraform-provider-sonarqube/issues/54 on a similar approach and why it was rejected. Over and above, that, inheriting the rules from another profile and then having both active and inactive overrides seems destined to cause problems - what if you put a rule in both sections - what is the behaviour then? And if I remove a rule from inactive, does that now make it active? Or only active if it was in the parent profile? If a rule is not in the “active_rules” list is it not active at all or again only if it was active in the parent?

The discussion I linked you to describes an approach I have used in the past - build a list of rules from the Sonar Way profile, minus ones I don’t want at all and with some customised where required, then for-each the list and add them as individual resources.

I would prefer it if the qualityprofile resource followed a similar model to the qualitygate one: https://registry.terraform.io/providers/jdamata/sonarqube/latest/docs/resources/sonarqube_qualitygate where better model the relationships between resources rather than being a thin wrapper around the existing Sonar API but that is a bigger refactor for another day..

[ff00ff2337]

Thanks for the feedback Regarding proposed scenarios - both rule lists override parent quality profile rule list. Like I mentioned, both attributes have "ForceNew: true" set, so there no changes to active if you remove rule from inactive list and vice versa. If rule exist in both lists - then it is going to be active rule. Solution you proposed is actually causing a lot of issues in dynamic environment. Currently, rule activation is a resource, and on deletion it deactivates this rule. While in the SonarQube side it is a state in context of quality profile. So, while any change in quality profile results in its recreation, all created activate_rule resources cannot be deleted or modified. Like I already mentioned, I'm highly interested in solving this problem, so I'm looking forward to hearing your insights.

[freeranger]

Hi

both rule lists override parent quality profile rule list. Like I mentioned, both attributes have "ForceNew: true" set, so there no changes to active if you remove rule from inactive list and vice versa. If rule exist in both lists - then it is going to be active rule.

How does a user know this is the case?

• If I put nothing in either list, are any active or are they all inactive?
• Why would putting a rule in both lists mean it is active? Is this deterministic and obvious to the user?
• How does any of this feed into the sonarqube_qualityprofile_activate_rule?
  • If I have a resource for a rule and then it is listed in yourinactive_rules then does it end up active or not?
  • Should I use only this or only active_rules or can I use both at the same time? And what is the difference between them?

It seems like this will simply cause confusion and open up a load of questions with non-obvious answers as well as potentially conflicting with the existing sonarqube_qualityprofile_activate_rule resource so for me, this is not a good solultion - though @jdamata may have other thoughts on this and it is, after all, his repo.

Solution you proposed is actually causing a lot of issues in dynamic environment.

I'm not sure what you mean by a "dynamic" environment?

In my case what I did was create one sonarqube_qualityprofile_activate_rule per rule I wanted in the profile by looping around a collection of rules I built using a http call to the Sonar API (because there is currently no such data source in this provider) If I don't want a rule anymore then I remove it from the collection and that specific instance is then removed from the profile. because the for_each around the collection results in a deletion of the rule resource(s) that I no longer need.

[rendevor]

Hi there.

short: I need this or similar feature too.

@freeranger you mention:

I have used in the past - build a list of rules from the Sonar Way profile.

This approach looks obvious, but how it works on every SonarQube update with new rules? How do you manage these rules, if you need to cover various projects with different requirements with tiny changes?

For example: you have three C++ projects, but they are for different platforms and different compilers (welcome to embedded world). A you going to make three profiles almost identical? Just curious, as I'm setting SonarQube right now and new MISRA rules comes every release.

So, from my use case I see it like the following:

1. Copy default Sonar Way to 3 additional profiles.
2. Amend each fresh profiles according to requirements removing rules out.
3. Bind projects with profiles.

From the terraform perspective I expect similar approach. If inactive rules are changed I expect that terraform will activate rules that are not in the list.

Unfortunately, I used to exclude rules via sonar-project.properties file and tune scanning per project by granting permissions to leads. Now I can handle this, because SonarLint ignores sonar-project.properties and I must transfer all customization to SonarQube to sync SonarLint and SonarScanner. And I must follow policy for tracking changes as code.

[freeranger]

We have only a few global profiles and in our case, because we chose to go that way, every new SonarQube with new rules will bring those rules into our profiles. We can explicitly exclude some reulrs and we can override the severity and other properties of specific rules per language we support.

Essentially we consider the SonarQube default rules as a starting point and add, remove, or update specific rules to suit our needs.