hashicorp / terraform-provider-google

Terraform Provider for Google Cloud Platform
https://registry.terraform.io/providers/hashicorp/google/latest/docs
Mozilla Public License 2.0
2.36k stars 1.75k forks source link

google_cloudbuild_trigger.pubsub_config.service_account_email produces perma diff #20051

Open IchordeDionysos opened 3 weeks ago

IchordeDionysos commented 3 weeks ago

Community Note

Terraform Version & Provider Version(s)

Terraform v1.9.3 on darwin_arm64

Affected Resource(s)

google_cloudbuild_trigger

Terraform Configuration

data "google_service_account" "default" {
  account_id = "example-service-account"
}

resource "google_pubsub_topic" "default" {
  name = "some-example-topic"
}

resource "google_cloudbuild_trigger" "default" {
  name        = "example-trigger"
  description = "Runs an example triggers."
  tags        = ["some-tag", "example-tag"]

  substitutions = {
    _COMMIT_SHA  = ""
    _ENVIRONMENT = "production"
  }
  service_account = data.google_service_account.default.name

  filename = "cloudbuild.yaml"

  pubsub_config {
    topic                 = google_pubsub_topic.default.id
    service_account_email = data.google_service_account.default.email
  }
}

Debug Output

https://gist.github.com/IchordeDionysos/09814666b86c79dd162c64c6a2e51bed

Expected Behavior

The second plan doesn't produce any diffs.

Actual Behavior

Planning the project with the configuration always results in diffs.

In the state file the service_account_email is empty:

"pubsub_config": [
  {
    "service_account_email": "",
    "state": "",
    "subscription": "projects/774205460629/subscriptions/gcb-example-trigger",
    "topic": "projects/simpleclub-hack-file-upload/topics/some-example-topic"
  }
],

What's interesting is that this warning is shown, which relates to the fact that the service_account_email is empty in the state:

[WARN]  Provider "provider[\"registry.terraform.io/hashicorp/google\"]" produced an unexpected new value for google_cloudbuild_trigger.default, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .disabled: was null, but now cty.False
      - .filter: was null, but now cty.StringVal("")
      - .include_build_logs: was null, but now cty.StringVal("")
      - .pubsub_config[0].service_account_email: was cty.StringVal("example-service-account@simpleclub-hack-file-upload.iam.gserviceaccount.com"), but now cty.StringVal("")

Steps to reproduce

  1. terraform apply
  2. terraform plan

Important Factoids

This happens if you use data.google_service_account.default.email and data.google_service_account.default.name.

The response of the creation operation of the trigger returns the service_account_email as it's passed.

Also, after creating the trigger, the GET request returns the service_account_email as it's passed.

References

No response

b/377499977

IchordeDionysos commented 3 weeks ago

Given the API responds with the field being set, this seems to be an issue on the provider side.

I did already check whether there is custom code that would alter the field? But here is nothing that would do that: https://github.com/GoogleCloudPlatform/magic-modules/blob/main/mmv1/products/cloudbuild/Trigger.yaml#L40-L44

IchordeDionysos commented 3 weeks ago

The parsing of the field service_account_email seems pretty standard, so I don't know where the issue may come from 😭

https://github.com/hashicorp/terraform-provider-google/blob/9cff2185d5169c9923e5f3bd03f2566828e69f8e/google/services/cloudbuild/resource_cloudbuild_trigger.go#L2496

ggtisc commented 2 weeks ago

Confirmed permadiff issue when data google_service_account is used for google_cloudbuild_trigger