feat: support for nested write-only arguments + write-only arguments for google_monitoring_notification_channel

[ramonvermeulen]

This PR introduces support for nested write-only fields and adds write-only arguments for the google_monitoring_notification_channel resource.

Closing: hashicorp/terraform-provider-google#21855

Release Note Template for Downstream PRs (will be copied)

See Write release notes for guidance.

monitoring: add write-only variants (`auth_token_wo` + `auth_token_wo_version`, `password_wo` + `password_wo_version`, `service_key_wo` + `service_key_wo_version`) for `google_monitoring_notification_channel.sensitive_labels`

firebaseailogic: fixed bug in `google_firebase_ai_logic_config.generative_language_config.api_key_wo` where the value set wouldn't be sent to the API. 

[ramonvermeulen]

When I do a local build, the ExactlyOneOf seems to have all the correct fields now:

ExactlyOneOf: []string{"sensitive_labels.0.auth_token", "sensitive_labels.0.password", "sensitive_labels.0.service_key", "sensitive_labels.0.auth_token_wo", "sensitive_labels.0.password_wo", "sensitive_labels.0.service_key_wo"},

---

@melinath

Let's discuss this feature further on this draft, I would like to validate with you if this aligns a bit with the original idea you had in mind for this feature.

[github-actions]

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

Googlers: For automatic test runs see go/terraform-auto-test-runs.

@melinath, 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.

[melinath]

yeah this looks like what I was imagining. It looks like the downstream generation worked fine / came out as expected, even for the case where multiple write only fields are added to the same constraint group 👍

Should be good to go once we have tests for the new fields.

[ramonvermeulen]

Should be good to go once we have tests for the new fields.

Great, I will try to add these tests today!

Do we also want to add some documentation about this logic somewhere? At least I can imagine without context reading this code for the first time might be a bit confusing, e.g. "why the ... do they apply this pointer logic?".

On the other hand it is also not that big of a change.

EDIT:
While adding the tests in c93f109 I also noticed the flatteners and expanders do not get generated, most likely because it is a "nested" field. I remember we never implemented the full support for nested fields (yet).

I will see what I can do to make it work. I think it is a unique case in general, because this use-case uses a custom encoder and url_param_only: true at https://github.com/ramonvermeulen/magic-modules/blob/03b0d07a70f6937bdbece2ecd47a367d449a809e/mmv1/products/monitoring/NotificationChannel.yaml#L104 which doesn't generate an expander for sensitive_labels to begin with.

[ramonvermeulen]

I will see what I can do to make it work.

I think I managed to address most of this in 8a48fca and ac2487d, unfortunately it is still quite some custom code, but that is also because sensitiveLabels seems to be quite a unique case. Can you retrigger the CI?

Tests on latest commit:

➜ make testacc TEST=./google/services/monitoring TESTARGS='-run=TestAccMonitoringNotificationChannel_'
sh -c "'/Users/ramon/go/src/github.com/hashicorp/terraform-provider-google/scripts/gofmtcheck.sh'"
==> Checking that code complies with gofmt requirements...
go vet
TF_ACC_REFRESH_AFTER_APPLY=1 TF_ACC=1 TF_SCHEMA_PANIC_ON_ERROR=1 go test ./google/services/monitoring -v -run=TestAccMonitoringNotificationChannel_ -timeout 240m -ldflags="-X=github.com/hashicorp/terraform-provider-google/version.ProviderVersion=acc"
=== RUN   TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== PAUSE TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== RUN   TestAccMonitoringNotificationChannel_update
=== PAUSE TestAccMonitoringNotificationChannel_update
=== RUN   TestAccMonitoringNotificationChannel_updateLabels_slack
    resource_monitoring_notification_channel_test.go:57:
--- SKIP: TestAccMonitoringNotificationChannel_updateLabels_slack (0.00s)
=== RUN   TestAccMonitoringNotificationChannel_updateLabels
=== PAUSE TestAccMonitoringNotificationChannel_updateLabels
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabels_slack
    resource_monitoring_notification_channel_test.go:107:
--- SKIP: TestAccMonitoringNotificationChannel_updateSensitiveLabels_slack (0.00s)
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== PAUSE TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
=== PAUSE TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo_slack
    resource_monitoring_notification_channel_test.go:216:
--- SKIP: TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo_slack (0.00s)
=== CONT  TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== CONT  TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== CONT  TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
=== CONT  TestAccMonitoringNotificationChannel_updateLabels
=== CONT  TestAccMonitoringNotificationChannel_update
--- PASS: TestAccMonitoringNotificationChannel_notificationChannelBasicExample (6.64s)
--- PASS: TestAccMonitoringNotificationChannel_updateLabels (8.15s)
--- PASS: TestAccMonitoringNotificationChannel_updateSensitiveLabels (10.79s)
--- PASS: TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo (14.25s)
--- PASS: TestAccMonitoringNotificationChannel_update (14.40s)
PASS
ok      github.com/hashicorp/terraform-provider-google/google/services/monitoring       15.182s

I only think the documentation for write-only arguments is still not generated fully correct. I think it makes sense to wait a little bit with that before #15385 is merged?

We most likely need to add some changes to this file to enable support for the nested write-only docs: https://github.com/GoogleCloudPlatform/magic-modules/blob/main/mmv1/templates/terraform/nested_property_documentation.html.markdown.tmpl.

[ramonvermeulen]

Applied the feedback, and reran tests locally:

❯ make testacc TEST=./google/services/monitoring TESTARGS='-run=TestAccMonitoringNotificationChannel_'                                                                                                                         ─╯
sh -c "'/Users/ramon/go/src/github.com/hashicorp/terraform-provider-google/scripts/gofmtcheck.sh'"
==> Checking that code complies with gofmt requirements...
go vet
TF_ACC_REFRESH_AFTER_APPLY=1 TF_ACC=1 TF_SCHEMA_PANIC_ON_ERROR=1 go test ./google/services/monitoring -v -run=TestAccMonitoringNotificationChannel_ -timeout 240m -ldflags="-X=github.com/hashicorp/terraform-provider-google/version.ProviderVersion=acc"
=== RUN   TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== PAUSE TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== RUN   TestAccMonitoringNotificationChannel_update
=== PAUSE TestAccMonitoringNotificationChannel_update
=== RUN   TestAccMonitoringNotificationChannel_updateLabels_slack
    resource_monitoring_notification_channel_test.go:57:
--- SKIP: TestAccMonitoringNotificationChannel_updateLabels_slack (0.00s)
=== RUN   TestAccMonitoringNotificationChannel_updateLabels
=== PAUSE TestAccMonitoringNotificationChannel_updateLabels
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabels_slack
    resource_monitoring_notification_channel_test.go:107:
--- SKIP: TestAccMonitoringNotificationChannel_updateSensitiveLabels_slack (0.00s)
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== PAUSE TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
=== PAUSE TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
=== RUN   TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo_slack
    resource_monitoring_notification_channel_test.go:216:
--- SKIP: TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo_slack (0.00s)
=== CONT  TestAccMonitoringNotificationChannel_notificationChannelBasicExample
=== CONT  TestAccMonitoringNotificationChannel_updateSensitiveLabels
=== CONT  TestAccMonitoringNotificationChannel_updateLabels
=== CONT  TestAccMonitoringNotificationChannel_update
=== CONT  TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo
--- PASS: TestAccMonitoringNotificationChannel_notificationChannelBasicExample (8.05s)
--- PASS: TestAccMonitoringNotificationChannel_updateLabels (9.51s)
--- PASS: TestAccMonitoringNotificationChannel_updateSensitiveLabels (12.35s)
--- PASS: TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo (15.97s)
--- PASS: TestAccMonitoringNotificationChannel_update (16.28s)
PASS
ok      github.com/hashicorp/terraform-provider-google/google/services/monitoring       17.084s

---

LGTM modulo this one change. I'll just go ahead and apply it - if you have concerns let me know & worst case we can handle in a small follow-up PR.

This introduces a couple changes outside the expected scope, but they seem fine/correct:

• Removes an expander for google_compute_network.routing_config.delete_bgp_always_compare_med. This is correct; that's a client-side only field, so we don't actually want to expand it.
• Fixes the path for a write-only field in google_firebase_ai_logic_config. This is a bugfix - the current logic won't work properly.

Thanks for reviewing! It is a bit of an complicated case, because essentially 3 client-side fields write to the same API field. I have been confused quite a couple of times during this implementation, but I feel like the decoder logic is still needed for sensitiveLabels. My main goal was to add the support for nested write-only arguments, because I think that is the final thing blocking to replace all the write_only_legacy implementations with the new write_only. Also there are some open write-only feature requests that will benefit from this change.

At least I think it would be nice if we can have these write_only_legacy implementations replaced before the next major release (which I assume is probably somewhere in ~september/october 2026).

[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 ( 9 files changed, 494 insertions(+), 26 deletions(-))
google-beta provider: Diff ( 10 files changed, 495 insertions(+), 34 deletions(-))
terraform-google-conversion: Diff ( 8 files changed, 352 insertions(+), 43 deletions(-))

[modular-magician]

Non-exercised tests

🔴 Tests were added that are skipped in VCR:

• TestAccMonitoringNotificationChannel_updateSensitiveLabelsWo_slack

Tests analytics

Total tests: 5988
Passed tests: 5352
Skipped tests: 634
Affected tests: 2

Click here to see the affected service packages

All service packages are affected

Action taken

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

• TestAccAccessContextManager__service_perimeter_dry_run_egress_policy
• TestAccAccessContextManager__service_perimeter_dry_run_ingress_policy

Get to know how VCR tests work

[modular-magician]

🟢 Tests passed during RECORDING mode:
TestAccAccessContextManager__access_level [Debug log]
TestAccAccessContextManager__access_level_condition [Debug log]
TestAccAccessContextManager__access_level_custom [Debug log]
TestAccAccessContextManager__access_level_full [Debug log]
TestAccAccessContextManager__access_levels [Debug log]
TestAccAccessContextManager__access_policy [Debug log]
TestAccAccessContextManager__access_policy_scoped [Debug log]
TestAccAccessContextManager__authorized_orgs_desc [Debug log]
TestAccAccessContextManager__service_perimeter [Debug log]
TestAccAccessContextManager__service_perimeter_dry_run_egress_policy [Debug log]
TestAccAccessContextManager__service_perimeter_dry_run_ingress_policy [Debug log]
TestAccAccessContextManager__service_perimeter_update [Debug log]
TestAccAccessContextManager__service_perimeters [Debug log]

🔴 Tests failed when rerunning REPLAYING mode:
TestAccAccessContextManager__service_perimeter_dry_run_egress_policy [Error message] [Debug log]
TestAccAccessContextManager__service_perimeter_dry_run_ingress_policy [Error message] [Debug log]

Tests failed due to non-determinism or randomness when the VCR replayed the response after the HTTP request was made.

Please fix these to complete your PR. If you believe these test failures to be incorrect or unrelated to your change, or if you have any questions, please raise the concern with your reviewer.

---

🟢 All tests passed!

View the build log or the debug log for each test

[melinath]

Failures look unrelated.

[melinath]

At least I think it would be nice if we can have these write_only_legacy implementations replaced before the next major release (which I assume is probably somewhere in ~september/october 2026).

I just opened hashicorp/terraform-provider-google#25965 yesterday to track the work to convert write_only_legacy fields. I think we'll still need to make some breaking changes in the major release, but I think this PR is also necessary.