Stephen Lewis (Burrows)
Stephen Lewis (Burrows)
~It may not be possible to _always_ autogenerate this, but we could almost certainly autogenerate the trivial case.~ Correction: this is extracting the id rather than autogenerating it from vars...
I believe the goal here would be to eliminate lines like https://github.com/GoogleCloudPlatform/magic-modules/blob/ca3b14e9c32eac9356cd050ecc428f5df5f04fa2/mmv1/products/apigee/Environment.yaml#L66, which are a common cause of errors on PRs (because they require understanding exactly how primary_resource_name is used...
Just ran into this again on https://github.com/GoogleCloudPlatform/magic-modules/pull/10670 - this ended up causing several rounds of extra review.
If there is any usage of `primary_resource_name` left, we should rename the field as discussed in https://github.com/hashicorp/terraform-provider-google/issues/13983
ran into this again on https://github.com/GoogleCloudPlatform/magic-modules/pull/10786 - the contributor skipped import tests to avoid the issue, which would have caused bugs in the import_format to be missed.
> Note: we should include a generation error when a primary_resource_name field is missing in example. This is a good idea but out of scope for this ticket.
@trodge I think we need to extract the field values from the state because we don't have an easy way to determine what the values are (which would be necessary...
We should probably also factor any checking behavior left over out into a separate function that we can fully unit test.
Note from triage: the value could also be empty on update, if the API can return an empty value for the field (which would then get propagated).
Should be possible to do, ~since it would only rely on the yaml~ - just takes a little more work.