jdamata / terraform-provider-sonarqube

Terraform provider for managing Sonarqube configuration
GNU General Public License v3.0
62 stars 54 forks source link

Issues when deleting quality gates #158

Closed Cesarsk closed 1 year ago

Cesarsk commented 1 year ago

Hello, I have an issue when deleting a quality gate. The default always changes to the "sonar way" one, regardless of which one is the actual set as default one. When deleting Quality Gates, the instance of Sonarqube also breaks because of this because the /qualitygates/list does not respond 200 anymore

A fix to restore the instance is to create a dummy quality gate using the /qualitygates/create?name=test and then /qualitygates/set_as_default/test

Why do you need to always invoke the set_as_default when destroying a quality gate? I think we need it only if the quality gate to be destroyed is set as default.

Link below:

https://github.com/jdamata/terraform-provider-sonarqube/blob/e230cdf842cf6a0beaf46419903d8d0ed8e8ef52/sonarqube/resource_sonarqube_qualitygate.go#L199

Best, l

tbutler-qontigo commented 1 year ago

Hi In looking at how to solve https://github.com/jdamata/terraform-provider-sonarqube/issues/154, I was coincidentally thinking about this problem earlier. I don't think creating a dummy one is a good option tbh...but this is not my repo so what do I know? :)

I think for sure if the quality gate we are deleting is not the default one then we should be able to avoid making that call to the API.

It is more problematic if

  1. This actually is the default one and we are deleting it
  2. This is the default one and we are simply changing is_default to false.

In case 1, if we have not set another gate as default then presumably it should be okay to set the default to Sonar way This gate always exists and cannot be deleted so setting this as default should work I'd have thought? You seem to be saying it is causing a problem though - do you have any more details on why you think this is not working?

In case 2, assuming we have not set another quality gate explicitly as default then again Sonar way should be fine.

The real problem IMO is if we are setting a different profile as default - either we are deleting the existing default or we are simply making the existing one non-default and setting another one as default.

Lets say we have:

resource "sonarqube_qualitygate" "way" {
  name       = "My way"
  is_default = true
}

resource "sonarqube_qualitygate" "other" {
  name       = "My Other way"
}

and we want to swap them around:

resource "sonarqube_qualitygate" "way" {
  name       = "My way"
}

resource "sonarqube_qualitygate" "other" {
  name       = "My Other way"
  is_default = true
}

In this case, how does the provider know what to do?
If the update operation for My way runs first then it could set Sonar way as the default (because it doesn't know that another update is coming on another resource) and then the update to My Other way will set that gate to default.

If the update operation for My way runs second then I guess it could find out that it is not the default and simply do nothing except update the terraform state.

If they ran at the same time (I believe terraform likes to run things in parallel right?) then all bets are off - I don't know where we would end up...

tbutler-qontigo commented 1 year ago

@Cesarsk Testing this, I can't recreate a problem where api/qualitygates/list does not work if the default profile is set to Sonar way

https://github.com/jdamata/terraform-provider-sonarqube/pull/160 should address the issue of the default being changed if the gate you are deleting is not the default one. The problem of "what if they run at the same time" didn't seem to be an issue in testing - maybe it is something that there is only a miniscule chance of happening....not sure if I got lucky or if in practise it wouldn't be an issue.

Cesarsk commented 1 year ago

Tested and on my end it's working. Thanks a lot for quickly addressing it.