added sonarqube_qualityprofile_deactivate_rule function

[ff00ff2337]

Added function to deactivate rule in a qualityprofile

resource "sonarqube_qualityprofile" "py_ckecks" {
    name     = "Inherited py checks for deactiovation tests"
    language = "py"
    is_default = false
    parent = "Sonar way"
}

data "sonarqube_rule" "itterator" {
  key = "python:S2876"
}
resource "sonarqube_qualityprofile_deactivate_rule" "inactive_rule" {
    key = sonarqube_qualityprofile.py_ckecks.key
    rule = data.sonarqube_rule.itterator.key 
}

[freeranger]

This doesn’t really feel to me like the “terraform way” - you are creating a resource which actually deletes a rule “resource”…and then if this resource was removed, then the rule is added in again? It seems to me that this has high potential to cause confusion if the behaviour is essentially the exact opposite of what one would expect “adding” a resource to do.

The SonarQube API model is a very poor one IMO and I think we should be more trying to adapt that to the terraform way of doing things than trying to adapt terraform to expose this poor API model.

With that in mind, a quality profile resource has rule sub resources. You want a new rule? Add it to the profile resource You don’t want a rule? Remove it from the profile resource

[ff00ff2337]

Thank you for your feedback. I understand your concerns about the approach of creating a resource that deletes a rule. While I agree that it may seem counterintuitive at first, I would like to provide some arguments for adding this function. The recommended way to create SonarQube qualityprofiles is to inherit them from the default one. That allows to ensure that the profiles receive updates and improvements over time. However, this can result in a situation where a large number of rules are enabled by default, without a straightforward way to disable them in Terraform (outside of explicitly declaring them and then deleting, which is not a terraform way either). Because this is the problem I currently struggle with, I hope you can share your insights on how to have fine-grained control over the rules enabled with both terraform and SonarQube best practices in mind.

[ff00ff2337]

Would it be considered the Terraform way if, instead of creating separate resources for rule activation(which are already implemented in Terraform) and deactivation , the required rules could be passed as arguments during the creation of the quality profile resource? Something like this:

resource "sonarqube_qualityprofile" "py_ckecks" {
    name     = "Inherited py checks for deactiovation tests"
    language = "py"
    is_default = false
    parent = "Sonar way"
    inactive_rules = [
      "python:S5850",
      "python:S2876",
    ]
    active_rules = {
      "python:S101" = "MINOR",
    }
}

Also arguments can have ForceNew: true, so on change quality profile can be recreated from the default one from the ground up without all the confusion that comes with rule activation now?

[ff00ff2337]

Created new pull request with proposed changes https://github.com/jdamata/terraform-provider-sonarqube/pull/241 This pull request is closed