magic-modules compute: added `shared_secret_wo` and `shared_secret_wo_version` fields to `google_compute_vpn_tunnel` + changes to `write_only` implementation in generator/templating

Closes https://github.com/hashicorp/terraform-provider-google/issues/23058

Release Note Template for Downstream PRs (will be copied)

compute: added `shared_secret_wo` and `shared_secret_wo_version` fields to `google_compute_vpn_tunnel`

May 29 '25 16:05 ramonvermeulen

I am struggling a bit with the implementation, because of the following part in the template:

https://github.com/GoogleCloudPlatform/magic-modules/blob/d1f449233e3b8b2d13a1625e59c0bd9ff49958d6/mmv1/templates/tgc/resource_converter.go.tmpl#L84

Because sharedSecret as well as sharedSecretWo share the same API name (sharedSecret), the yaml config generates the following:

	sharedSecretProp, err := expandComputeVpnTunnelSharedSecret(d.Get("shared_secret"), d, config)
	if err != nil {
		return err
	} else if v, ok := d.GetOkExists("shared_secret"); !tpgresource.IsEmptyValue(reflect.ValueOf(sharedSecretProp)) && (ok || !reflect.DeepEqual(v, sharedSecretProp)) {
		obj["sharedSecret"] = sharedSecretProp
	}
	sharedSecretProp, err := expandComputeVpnTunnelSharedSecretWo(d.Get("shared_secret_wo"), d, config)
	if err != nil {
		return err
	} else if v, ok := d.GetOkExists("shared_secret_wo"); !tpgresource.IsEmptyValue(reflect.ValueOf(sharedSecretProp)) && (ok || !reflect.DeepEqual(v, sharedSecretProp)) {
		obj["sharedSecret"] = sharedSecretProp
	}

Causing an error on the second generation of sharedSecretProp, would love some guidance on how to implement write-only arguments in a correct way.

You can see the error in the unit tests as well:

I took https://github.com/GoogleCloudPlatform/magic-modules/blob/89b90c054232fba6a435596b114af78dea534c78/mmv1/products/secretmanager/SecretVersion.yaml#L167 as an example, however, in the secret manager variant this problem is solved via a custom_expand. But that is only possible if the write only argument is nested at least 1 level deep.

May 29 '25 16:05 ramonvermeulen

This has been one of my deepest debugging sprees so far into the internals of magic-modules.

I have the feeling my yaml configuration was as it should be for implementing write-only arguments, however, my tests kept failing. To eventually get write-only arguments to work with my yaml configuration I had to do quite some debugging into how the code for write-only argument is generated.

I would love to hear your thoughts on this and the changes that I made, I followed the terraform provider sdk page on write-only arguments as reference. But possibly I was implementing my yaml incorrect in the first place, and some of the changes I made to the templates are not required (I don't know all the ins and outs, and possible impact).

Some key changes I made to the resource generation templates:

Changed p.IgnoreRead to p.IgnoreRead || p.WriteOnly for the ReadProperties of a resource. I don't see a scenario where you want to read back a "write-only" argument from the API, but maybe I am missing something?
Added {{if $prop.WriteOnly -}}Wo{{- end}} suffix to the expand functions, because of naming conflicts when two arguments use the same api field (which is the case with write-only) see https://github.com/GoogleCloudPlatform/magic-modules/pull/14138#issuecomment-2919944025
Added {{ else if $prop.WriteOnly }}getRawConfigAttributeAsString(d, "{{ underscore $prop.Name }}"){{ else }}, it seemed like in the old situation for the expand function the write-only argument was retrieved from the plan (via d.Get("{{underscore $prop.Name}}"), at least this was always empty), while the documentation states it can only be retrieved from config, I used this as reference.
Added to condition to not generate flatten (just like ignore_read), since (I think) you do not need this anyways for a write-only argument

Local acceptance tests:

❯ make testacc TEST=./google/services/compute TESTARGS='-run=TestAccComputeVpnTunnel_'

TF_ACC=1 TF_SCHEMA_PANIC_ON_ERROR=1 go test ./google/services/compute -v -run=TestAccComputeVpnTunnel_ -timeout 240m -ldflags="-X=github.com/hashicorp/terraform-provider-google/version.ProviderVersion=acc"
=== RUN   TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== PAUSE TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== RUN   TestAccComputeVpnTunnel_regionFromGateway
=== PAUSE TestAccComputeVpnTunnel_regionFromGateway
=== RUN   TestAccComputeVpnTunnel_router
=== PAUSE TestAccComputeVpnTunnel_router
=== RUN   TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== PAUSE TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== RUN   TestAccComputeVpnTunnel_defaultTrafficSelectors
=== PAUSE TestAccComputeVpnTunnel_defaultTrafficSelectors
=== CONT  TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== CONT  TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== CONT  TestAccComputeVpnTunnel_defaultTrafficSelectors
=== CONT  TestAccComputeVpnTunnel_router
=== CONT  TestAccComputeVpnTunnel_regionFromGateway
--- PASS: TestAccComputeVpnTunnel_router (156.26s)
--- PASS: TestAccComputeVpnTunnel_vpnTunnelBasicExample (204.51s)
--- PASS: TestAccComputeVpnTunnel_regionFromGateway (227.94s)
--- PASS: TestAccComputeVpnTunnel_defaultTrafficSelectors (249.41s)
--- PASS: TestAccComputeVpnTunnel_routerWithSharedSecretWo_update (287.52s)
PASS
ok      github.com/hashicorp/terraform-provider-google/google/services/compute  288.258s

The tfstate after local apply via manual testing:

May 29 '25 21:05 ramonvermeulen

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.

May 29 '25 21:05 github-actions[bot]

@melinath This PR has been waiting for review for 3 weekdays. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jun 03 '25 09:06 github-actions[bot]

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 ( 619 files changed, 4530 insertions(+), 15 deletions(-)) google-beta provider: Diff ( 673 files changed, 4908 insertions(+), 15 deletions(-)) terraform-google-conversion: Diff ( 1 file changed, 10 insertions(+))

Breaking Change(s) Detected

The following breaking change(s) were detected within your pull request.

Field shared_secret_wo_version added as optional with a default value and force new on pre-existing resource google_compute_vpn_tunnel. This can be allowed if there is a confirmed API-level default that matches the schema default - reference

If you believe this detection to be incorrect please raise the concern with your reviewer. If you intend to make this change you will need to wait for a major release window. An override-breaking-change label can be added to allow merging.

Missing doc report (experimental)

The following resources have fields missing in documents.

google_compute_vpn_tunnel
- Expected Document Path: /website/docs/r/compute_vpn_tunnel.html.markdown
- Fields: [shared_secret_wo]

Jun 03 '25 23:06 modular-magician

So, you've stumbled on an area that is not well-lit and has a lot of rough edges. If you would like to make significant contributions to the generator logic, that is probably something we would accept, but we may need to come to consensus on our end on some points first. For example, we may want to automatically generate the *Version field similar to how we handle adding sibling fields for labels fields.

Any contribution making significant generator changes will need to start out as only changing generator logic and cleaning up various parts of the handwritten code that was necessary for the initial PR implementing a few write-only fields: #13135 Probably split into multiple PRs to clean up various portions. Once that refactor was done, we could then think about adding new fields.

Alternatively, you could likely follow the patterns of the original PR to add support with no template changes. In particular, you would need to add a custom_expand on the parent field and add a raw_resource_config_validation custom code template.

If you're open to / interested in working on the generator changes, I can put together a more formal list of refactors we'd want to see - lmk!

I see, and that also makes a lot of sense to me. There are most likely a lot of edge cases (that I definitely cannot grasp on my own), and changes to the generator code can (and most likely will) have significant downstream impact. Therefore I mainly made these changes to open up the discussion itself, and demonstrate how in my head the ideal yaml configuration would look like for write only arguments (combination of api_name: 'sharedSecret' and write_only: true), but I am interested in your (and other maintainers) their thoughs on this. For this specific implementation my changes to the generator seem to work, but I suspect it will break a lot of other implementations ;)

I am definitely open to contribute to the generator code, with the goal of making the addition of write-only arguments more standardized, straight-forward, and better documented where possible. Would love to hear your (and possibly other maintainers) there thoughts in this idea. Maybe we could open an issue in the provider, describing the desired config and list of refactors we'd want to see?

Some other thoughts:

Good point about generating the *Version field similar to how adding sibling fields for labels fields is handled. This seems like a good idea to me, you need to add the _wo_version field anyways for every write-only implementation, so I think it will be nice if this can be standardized and generated for you.
If this is indeed an aspect within magic-modules that is desired to get improved, I think the refactor is easier to do now than in for example 1 or 2 years. Write-only arguments are still fairly new, but the amount of write-only implementations will probably grow over the years, making the impact of a refactor on this subject bigger and harder.
For now moving forward with the same pattern as on the original PR #13135 seems like a good idea to me, I will take a look and see if I am able to implement write-only attributes for this PR in a similar manner. Would you like to see that on this specific PR, or rather keep this one open for reference for the refactor? And open another PR to implement the shared_secret_wo for google_compute_vpn_tunnel in the patterns of the original PR?

Jun 04 '25 07:06 ramonvermeulen

Tests analytics

Total tests: 4650 Passed tests: 4221 Skipped tests: 422 Affected tests: 7

Click here to see the affected service packages

resourcemanager

bigquery

dataprocmetastore

activedirectory

backupdr

bigqueryreservation

cloudrunv2

deploymentmanager

iambeta

artifactregistry

beyondcorp

dataform

memcache

cloudids

cloudquotas

logging

redis

storagecontrol

billing

dialogflowcx

cloudrun

discoveryengine

firebaseextensions

servicedirectory

transcoder

accessapproval

clouddomains

dataplex

essentialcontacts

gkeonprem

bigquerydatatransfer

datacatalog

firebasestorage

iam2

datastream

documentai

lustre

networkconnectivity

networkservices

privateca

bigquerydatapolicy

composer

filestore

sourcerepo

alloydb

datafusion

cloudidentity

cloudtasks

colab

containeranalysis

firebasedataconnect

iam3

bigqueryconnection

cloudfunctions2

vmwareengine

securitycenterv2

tpu

firebasedatabase

iap

orgpolicy

pubsublite

secretmanager

storagetransfer

blockchainnodeengine

clouddeploy

kms

oracledatabase

datapipeline

developerconnect

iamworkforcepool

managedkafka

parallelstore

appengine

eventarc

parametermanagerregional

securitycenter

storage

dialogflow

integrationconnectors

firebaseapphosting

migrationcenter

networksecurity

vpcaccess

chronicle

cloudbuild

containerattached

siteverification

netapp

parametermanager

biglake

gkehub

gkehub2

securesourcemanager

sql

accesscontextmanager

bigqueryanalyticshub

privilegedaccessmanager

resourcemanager3

tpuv2

databasemigrationservice

edgecontainer

securityposture

edgenetwork

firebaseappcheck

storagebatchoperations

workflows

workstations

firebasehosting

serviceusage

cloudscheduler

secretmanagerregional

apphub

cloudasset

integrations

networkmanagement

notebooks

pubsub

securitycentermanagement

vertexai

apigee

corebilling

dataprocgdc

oslogin

dns

looker

storageinsights

binaryauthorization

compute

apihub

datalossprevention

monitoring

osconfig

osconfigv2

securityscanner

healthcare

mlengine

bigtable

gkebackup

documentaiwarehouse

firebase

firestore

identityplatform

memorystore

servicenetworking

apigateway

cloudbuildv2

spanner

gemini

publicca

tags

workbench

certificatemanager

dataproc

#### Action taken

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

TestAccAccessContextManager

TestAccDataSourceGoogleGkeHubFeature_basic

TestAccComputeFirewallPolicyWithRules_computeFirewallPolicyWithRulesFullExample

TestAccComputeFirewallPolicyWithRules_update

TestAccComputeVpnTunnel_routerWithSharedSecretWo_update

TestAccHealthcarePipelineJob_healthcarePipelineJobBackfillExample

TestAccGeminiGeminiGcpEnablementSettingBinding_update

Get to know how VCR tests work

Jun 04 '25 07:06 modular-magician

🟢 Tests passed during RECORDING mode: TestAccAccessContextManager [Debug log] TestAccComputeVpnTunnel_routerWithSharedSecretWo_update [Debug log] TestAccDataSourceGoogleGkeHubFeature_basic [Debug log]

🔴 Tests failed when rerunning REPLAYING mode: TestAccDataSourceGoogleGkeHubFeature_basic [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.

🔴 Tests failed during RECORDING mode: TestAccComputeFirewallPolicyWithRules_computeFirewallPolicyWithRulesFullExample [Error message] [Debug log] TestAccComputeFirewallPolicyWithRules_update [Error message] [Debug log] TestAccGeminiGeminiGcpEnablementSettingBinding_update [Error message] [Debug log] TestAccHealthcarePipelineJob_healthcarePipelineJobBackfillExample [Error message] [Debug log]

🔴 Errors occurred during RECORDING mode. Please fix them to complete your PR.

View the build log or the debug log for each test

Jun 04 '25 08:06 modular-magician

If this is indeed an aspect within magic-modules that is desired to get improved, I think the refactor is easier to do now than in for example 1 or 2 years. Write-only arguments are still fairly new, but the amount of write-only implementations will probably grow over the years, making the impact of a refactor on this subject bigger and harder.

Big +1 to this.

For now moving forward with the same pattern as on the original PR https://github.com/GoogleCloudPlatform/magic-modules/pull/13135 seems like a good idea to me, I will take a look and see if I am able to implement write-only attributes for this PR in a similar manner. Would you like to see that on this specific PR, or rather keep this one open for reference for the refactor? And open another PR to implement the shared_secret_wo for google_compute_vpn_tunnel in the patterns of the original PR?

Yeah, if you'd like to move forward with this specific change before modifying the generator logic, doing so on this PR seems reasonable.

Jun 04 '25 16:06 melinath

@ramonvermeulen After talking things over with @BBBmau, we'd actually like to ask you to make the generator changes first, then the resource changes after. We're working on putting together a plan for what generator changes will be required - should have that ready in a few days.

Apologies for the back-and-forth!

Jun 04 '25 18:06 melinath

@ramonvermeulen After talking things over with @BBBmau, we'd actually like to ask you to make the generator changes first, then the resource changes after. We're working on putting together a plan for what generator changes will be required - should have that ready in a few days.

Apologies for the back-and-forth!

No problem, haven't worked on this in the meantime.

Sounds like a good idea! Might not be worth the effort to first do a more custom implementation on this PR, then make the generator changes, and then have to refactor the "more custom implementation" from this PR right away.

Jun 05 '25 11:06 ramonvermeulen

@melinath This PR has been waiting for review for 3 weekdays. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jun 09 '25 09:06 github-actions[bot]

@ramonvermeulen thanks for the patience! We've opened github issues in regards to the refactoring work you've expressed interest in

https://github.com/hashicorp/terraform-provider-google/issues/23210#issue-3131689461

You'll want to open the PRs onto a refactoring branch (refactor-write-only). Once we have all that's needed for the refactor merged we can then proceed with merging refactor-write-only into main.

Jun 09 '25 23:06 BBBmau

@BBBmau wouldn't it be easier to merge each part of the fix directly into main like normal? The incremental changes should be safe?

Jun 09 '25 23:06 melinath

@BBBmau wouldn't it be easier to merge each part of the fix directly into main like normal? The incremental changes should be safe?

we can do normal merges to main also since like you said these changes are safe to do.

Jun 09 '25 23:06 BBBmau

@melinath @BBBmau

Thanks for following up on this! 🙌

Just a small FYI, from this Thursday 12th till Monday 16th I am out-of-office, so I will probably follow up on most of the work after the 16th. I am fine with either approaches, of doing all the subtasks in one big PR (e.g. refactor-write-only branch), or each in an individual PR (e.g. refactor-write-only-<issue-number> branches).

Are you sure the incremental changes should be safe to merge separately? Just high-over thinking about the refactor, for example I can imagine https://github.com/hashicorp/terraform-provider-google/issues/23213 (eliminating the need of *_wo_version) conflicting with "existing" wo implementations, resulting in for example a double wo_version (e.g. original one + the one being generated with new generation code). Unless it will really be based upon a field configuration such as generate_wo_version: true next to write_only: true.

EDIT:

Another thought on the generated *_wo_version, I guess the required_with logic should also be automatically generated, e.g. where you used to do:

        required_with:
          - 'password_wo'

Also, do we still want the user to set this on a write-only field or generate such logic as well?:

        conflicts:
          - 'password'

I think it might be better to keep that part as it is, because it offers slightly more flexibility. Maybe we also need to add a subtask to add/update the documentation for users on how to add write-only fields?

Desired end config from a user perspective would look like?:

  - name: 'password'
    type: String
    description: |
      foo
    ignore_read: true
    sensitive: true
    # cannot configure both at the same time
    exactly_one_of:
      - 'password'
      - 'password_wo'
    conflicts:
      - 'password_wo'
  - name: 'passwordWo'
    type: String
    description: |
      bar
    # so that the same underlaying field will be used during resource creation
    api_name: 'password'
    write_only: true
    # cannot configure both at the same time (not sure if this configuration is required on both ends)
    exactly_one_of:
      - 'password'
      - 'password_wo'
    conflicts:
      - 'password'
    # not sure if we want to do this "explicit" or "implicit", in case we want this "explicit":
    generate_wo_version: true

Jun 10 '25 06:06 ramonvermeulen

we should avoid doing a single large branch. That said, each incremental change will need to be complete. For example, generating expander behavior should be in a separate PR from eliminating manual *_wo_version fields, but removing *_wo_version fields should include replacing the existing *_wo_version fields. (It might be possible to split some of the tickets into multiple PR stages for easier review.)

Jun 10 '25 16:06 melinath

regarding the UX, see https://github.com/hashicorp/terraform-provider-google/issues/23213#issuecomment-2959923206

Jun 10 '25 16:06 melinath

we should avoid doing a single large branch. That said, each incremental change will need to be complete. For example, generating expander behavior should be in a separate PR from eliminating manual *_wo_version fields, but removing *_wo_version fields should include replacing the existing *_wo_version fields. (It might be possible to split some of the tickets into multiple PR stages for easier review.)

@melinath @BBBmau Check, for generating the _wo and _wo_version properties, would it make more sense to do this from within the templating, or even before the templating within the data structure?

~For example by modifying the following method: https://github.com/GoogleCloudPlatform/magic-modules/blob/80c697e199a05c12ff68fb882fcf66d6fe3f4f0a/tpgtools/property.go#L517~

~I think this method loops over all the "parsed" properties, and applies recursion at several places, for instance for Object type properties. Thinking about it, it might make more sense to already solve the problem from within the data structure itself (which is the input for the templating).~

Another option is to do it slightly later, maybe in a similar manner as: https://github.com/GoogleCloudPlatform/magic-modules/blob/80c697e199a05c12ff68fb882fcf66d6fe3f4f0a/mmv1/main.go#L240

Would love to hear your opinion(s) about this approach.

Jun 10 '25 18:06 ramonvermeulen

Adding the new fields should happen at yaml parsing time, so that they look like they've "always been there" and can be handled like any other fields. It should be similar to how we handle label-related fields. I'll put more details on the ticket.

Jun 10 '25 18:06 melinath

Adding the new fields should happen at yaml parsing time, so that they look like they've "always been there" and can be handled like any other fields. It should be similar to how we handle label-related fields. I'll put more details on the ticket.

Check, this makes sense, so similar as: https://github.com/GoogleCloudPlatform/magic-modules/blob/80c697e199a05c12ff68fb882fcf66d6fe3f4f0a/mmv1/main.go#L240 https://github.com/GoogleCloudPlatform/magic-modules/blob/80c697e199a05c12ff68fb882fcf66d6fe3f4f0a/mmv1/api/resource.go#L713

And also apply recursion for NestedObject type properties to support "nested" write-only properties.

Jun 10 '25 19:06 ramonvermeulen

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 1 week. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jun 11 '25 09:06 github-actions[bot]

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 2 weeks. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jun 18 '25 09:06 github-actions[bot]

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 3 weeks. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jun 25 '25 09:06 github-actions[bot]

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 4 weeks. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jul 02 '25 09:07 github-actions[bot]

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 5 weeks. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jul 09 '25 09:07 github-actions[bot]

@GoogleCloudPlatform/terraform-team @melinath This PR has been waiting for review for 6 weeks. Please take a look! Use the label disable-review-reminders to disable these notifications.

Jul 16 '25 09:07 github-actions[bot]

@melinath tagging for visibility, since this is the first PR using the new write-only system.

With this PR I found out that I still had to do some changes to the generated expander logic to make this work (https://github.com/hashicorp/terraform-provider-google/issues/23211). At first glance I thought it wasn't necessary because for the existing _wo arguments it generated without issues, but apparently it is required for this one.

For example, if it stays just {{ $prop.ApiName }}Prop := ... you will get conflicting variable names, and d.Get cannot be used to retrieve the write-only value, instead d.GetRawConfig(...) should be used. I could also move this to a seperate PR if that is preferred.

Tests:

❮ make testacc TEST=./google/services/compute TESTARGS='-run=TestAccComputeVpnTunnel_ -parallel 3'
TF_ACC=1 TF_SCHEMA_PANIC_ON_ERROR=1 go test ./google/services/compute -v -run=TestAccComputeVpnTunnel_ -parallel 3 -timeout 240m -ldflags="-X=github.com/hashicorp/terraform-provider-google/version.ProviderVersion=acc"
=== RUN   TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== PAUSE TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== RUN   TestAccComputeVpnTunnel_regionFromGateway
=== PAUSE TestAccComputeVpnTunnel_regionFromGateway
=== RUN   TestAccComputeVpnTunnel_router
=== PAUSE TestAccComputeVpnTunnel_router
=== RUN   TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== PAUSE TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== RUN   TestAccComputeVpnTunnel_defaultTrafficSelectors
=== PAUSE TestAccComputeVpnTunnel_defaultTrafficSelectors
=== CONT  TestAccComputeVpnTunnel_vpnTunnelBasicExample
=== CONT  TestAccComputeVpnTunnel_routerWithSharedSecretWo_update
=== CONT  TestAccComputeVpnTunnel_defaultTrafficSelectors
--- PASS: TestAccComputeVpnTunnel_vpnTunnelBasicExample (224.41s)
=== CONT  TestAccComputeVpnTunnel_router
--- PASS: TestAccComputeVpnTunnel_defaultTrafficSelectors (252.69s)
=== CONT  TestAccComputeVpnTunnel_regionFromGateway
--- PASS: TestAccComputeVpnTunnel_routerWithSharedSecretWo_update (318.62s)
--- PASS: TestAccComputeVpnTunnel_router (156.78s)
--- PASS: TestAccComputeVpnTunnel_regionFromGateway (228.20s)
PASS
ok      github.com/hashicorp/terraform-provider-google/google/services/compute  481.826s

P.S. I also played a bit around on another PR for write-only arguments and found out that currently exactly_one_of will cause some problems when you have multiple write-only fields. Just a small heads-up that the write-only generation probably still requires a couple iterations before it tackles all cases.

Aug 11 '25 13:08 ramonvermeulen

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 ( 649 files changed, 4753 insertions(+), 27 deletions(-)) google-beta provider: Diff ( 702 files changed, 5125 insertions(+), 28 deletions(-)) terraform-google-conversion: Diff ( 1 file changed, 10 insertions(+))

Missing doc report (experimental)

The following resources have fields missing in documents.

google_compute_vpn_tunnel
- Expected Document Path: /website/docs/r/compute_vpn_tunnel.html.markdown
- Fields: [shared_secret_wo]

Aug 11 '25 16:08 modular-magician

Tests analytics

Total tests: 4671 Passed tests: 4232 Skipped tests: 435 Affected tests: 4

Click here to see the affected service packages

parallelstore

redis

vpcaccess

appengine

colab

privilegedaccessmanager

siteverification

servicenetworking

apigee

bigquery

looker

osconfigv2

gkehub

healthcare

transcoder

certificatemanager

cloudrun

containeranalysis

firebase

memorystore

parametermanagerregional

containerattached

dataplex

identityplatform

memcache

cloudids

firebasedatabase

migrationcenter

workstations

sql

tpuv2

artifactregistry

beyondcorp

iam2

notebooks

bigqueryanalyticshub

cloudbuild

securityposture

serviceusage

essentialcontacts

managedkafka

pubsublite

secretmanager

iap

storagebatchoperations

apigateway

bigqueryreservation

databasemigrationservice

dataprocgdc

apihub

gkehub2

iambeta

netapp

resourcemanager

tpu

blockchainnodeengine

cloudtasks

gkeonprem

oslogin

firebaseappcheck

firebasedataconnect

logging

networkconnectivity

contactcenterinsights

datapipeline

deploymentmanager

documentaiwarehouse

publicca

filestore

kms

monitoring

edgenetwork

firebaseextensions

oracledatabase

secretmanagerregional

activedirectory

cloudbuildv2

composer

datalossprevention

storagecontrol

compute

iamworkforcepool

modelarmorglobal

vmwareengine

binaryauthorization

cloudidentity

networkmanagement

sourcerepo

dns

cloudfunctions2

developerconnect

spanner

billing

storageinsights

eventarc

gemini

modelarmor

privateca

apphub

discoveryengine

documentai

edgecontainer

securitycentermanagement

workflows

dataprocmetastore

networkservices

orgpolicy

storagetransfer

bigtable

clouddeploy

datacatalog

dataproc

bigquerydatatransfer

chronicle

dataform

iam3

osconfig

workbench

clouddomains

integrationconnectors

mlengine

securitycenterv2

accessapproval

resourcemanager3

firebasehosting

gkebackup

parametermanager

securitycenter

biglake

cloudquotas

datafusion

dialogflow

servicedirectory

vertexai

backupdr

firestore

networksecurity

firebaseapphosting

accesscontextmanager

alloydb

bigquerydatapolicy

corebilling

datastream

firebasestorage

securesourcemanager

storage

tags

bigqueryconnection

cloudasset

cloudscheduler

integrations

securityscanner

cloudrunv2

dialogflowcx

lustre

pubsub

Action taken

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

TestAccAccessContextManager

TestAccDialogflowEncryptionSpec_dialogflowEncryptionSpecBasicExample

TestAccHealthcarePipelineJob_healthcarePipelineJobBackfillExample

TestAccNetworkConnectivitySpoke_LinkedVPCNetworkHandWrittenLongForm

Get to know how VCR tests work

Aug 12 '25 00:08 modular-magician