fix permadiff issue in google_cloudfunctions2_function service_config.environment_variables

[daniel-cit]

fix permadiff issue in google_cloudfunctions2_function service_config.environment_variables hashicorp/terraform-provider-google#18747

Release Note Template for Downstream PRs (will be copied)

cloudfunctions2: fixed a "Provider produced inconsistent final plan" bug affecting the `service_config.environment_variables` field in `google_cloudfunctions2_function` resource

[github-actions]

Hello! I am a robot. Tests will require approval from a repository maintainer to run.

@SarahFrench, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[daniel-cit]

This is the difference from a case where the same change works
https://github.com/GoogleCloudPlatform/magic-modules/blob/c0299ff1ecd4a6850fac7566591139004a10bbb9/mmv1/products/workbench/Instance.yaml#L428C7-L433C63

See Fix a permadiff

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 1 file changed, 1 insertion(+))
google-beta provider: Diff ( 1 file changed, 1 insertion(+))

[modular-magician]

Tests analytics

Total tests: 18
Passed tests: 17
Skipped tests: 1
Affected tests: 0

Click here to see the affected service packages

• cloudfunctions2

$\textcolor{green}{\textsf{All tests passed!}}$

View the build log

[SarahFrench]

I'm at the end of my day and I'm OOO Monday and Tuesday so a 'proper' review will be delayed, but I had some thoughts from a quick look at your PR and your discussion in the linked issue that might unblock you in the meantime:

First, do you want to make the changes that you described in this comment to the environmentVariablesDiffSuppress function? If you did want to make that change you'd need to edit this file: cloudfunctions2_function.go.erb. Was there a reason for the different approach in this PR?

Second, it'd be great to have a minimal reproduction of the issue to see what conditions lead to the problem. Your discussion of the problem here was really useful and it sounds like reproduction of the issue could be achieved with a handful of resources (instead of the module shared in the linked issue). If that's the case it'd be useful to add or update an existing acceptance test to trigger this issue and then use it to confirm your PR solves the issue.

I'll resume review on Wednesday!

[daniel-cit]

I'm at the end of my day and I'm OOO Monday and Tuesday so a 'proper' review will be delayed, but I had some thoughts from a quick look at your PR and your discussion in the linked issue that might unblock you in the meantime:

First, do you want to make the changes that you described in this comment to the environmentVariablesDiffSuppress function? If you did want to make that change you'd need to edit this file: cloudfunctions2_function.go.erb. Was there a reason for the different approach in this PR?

Hi @SarahFrench Thanks for the review.

The approach for the fix in the discussion was based in a partial understanding of the root cause.

Later, comparing the case for the Cloud Function v2 with other exemples of the same type of permadiff function of a Map attribute that does not have the issue like the workbench metadata map helped to identify the real root cause.

The missing part was this instruction from the development guide regarding updating the yaml.

This was the only difference form the other cases where the same permadiff function worked and the problem was fixed with only this change.

Should the new test case be added here?

magic-modules/mmv1/templates/terraform/examples/cloudfunctions2_full.tf.erb

Lines 52 to 54 in d8061c7

	environment_variables = {
	SERVICE_CONFIG_TEST = "config_test"
	}

like

    environment_variables = {
        SERVICE_CONFIG_TEST      = "config_test"
        SERVICE_CONFIG_DIFF_TEST = google_storage_bucket.bucket.name
    }

[SarahFrench]

Should the new test case be added here?
magic-modules/mmv1/templates/terraform/examples/cloudfunctions2_full.tf.erb

like

    environment_variables = {
        SERVICE_CONFIG_TEST      = "config_test"
        SERVICE_CONFIG_DIFF_TEST = google_storage_bucket.bucket.name
    }

Yes, that should work. I'm hoping that that change will cause the test(s) generated from that example file to fail when your changes in this PR aren't present 🤞

[trodge]

I've opened a draft PR here: https://github.com/GoogleCloudPlatform/magic-modules/pull/11345/files to try out the change of adding SERVICE_CONFIG_DIFF_TEST = google_storage_bucket.bucket.name

If it fails as expected, feel free to pull it into this PR and we can confirm the fix.

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 3 files changed, 5 insertions(+), 2 deletions(-))
google-beta provider: Diff ( 3 files changed, 5 insertions(+), 2 deletions(-))

[modular-magician]

Tests analytics

Total tests: 18
Passed tests: 16
Skipped tests: 1
Affected tests: 1

Click here to see the affected service packages

• cloudfunctions2

Action taken

Found 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests

• TestAccCloudfunctions2function_cloudfunctions2FullExample

Get to know how VCR tests work

[modular-magician]

$\textcolor{green}{\textsf{Tests passed during RECORDING mode:}}$
TestAccCloudfunctions2function_cloudfunctions2FullExample[Debug log]

$\textcolor{green}{\textsf{No issues found for passed tests after REPLAYING rerun.}}$

---

$\textcolor{green}{\textsf{All tests passed!}}$

View the build log or the debug log for each test

[daniel-cit]

Hi @SarahFrench could you PTAL?

@trodge helped creating a draft PR to reproduce the error this PR is fixing

[SarahFrench]

Approving based on the fact the test fails when the test is updated but the schema isn't (b65255d, #11345 (comment)), and the test passes here due to the schema changes