Added support for versionAliases field in google_secret_manager_secret resource

[abheda-crest]

Added support for version_aliases field in google_secret_manager_secret resource.

If this PR is for Terraform, I acknowledge that I have:

• Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
• Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
• Generated Terraform providers, and ran make test and make lint in the generated providers to ensure it passes unit and linter tests.
• Ran relevant acceptance tests using my own Google Cloud project and credentials (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• Read Write release notes before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

secretmanager: added `version_aliases` field to `google_secret_manager_secret` resource

[modular-magician]

Hello! I am a robot. It looks like you are a community contributor. @NickElliot, 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.

[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.

Terraform GA: Diff ( 3 files changed, 276 insertions(+))
Terraform Beta: Diff ( 3 files changed, 276 insertions(+))
TF Conversion: Diff ( 3 files changed, 20 insertions(+), 3 deletions(-))

[modular-magician]

Tests analytics

Total tests: 2932
Passed tests 2628
Skipped tests: 302
Affected tests: 2

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

TestAccSecretManagerSecret_versionAliasesUpdate|TestAccBigQueryDataTable_bigtable

Get to know how VCR tests work

[modular-magician]

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

Rerun these tests in REPLAYING mode to catch issues

$\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

[NickElliot]

Looks good, but I want to clarify: is there a scenario you're trying to test for with the 5-step update test? The situation I assume of "you can add aliases and remove them" could be covered by a simpler 3-step test like there is for annotations.

[abheda-crest]

Looks good, but I want to clarify: is there a scenario you're trying to test for with the 5-step update test? The situation I assume of "you can add aliases and remove them" could be covered by a simpler 3-step test like there is for annotations.

Unlike the annotations field, we cannot provide the versionAliases field while creating the secret because the version alias can only be mapped to existing versions. Hence, the first step creates a secret without this field and multiple secret versions. The second step adds this field to the resource while the subsequent steps check various update scenarios such as updating keys, updating values, updating key-value pair, adding key-value pair, and removing key-value pair. The last step removes the entire version_aliases field from the resource.

[NickElliot]

I see, thank you for the explanation! In that case, would it be possible to remove just the 4th step, as repeating the testAccSecretManagerSecret_versionAliasesBasic version is not testing any functionality not tested via the original Basic-Updated version? I.e. step 3 is doing a key update, value update, removal, and addition, while step 4 repeats the same four operation tests.

Because of how TPG creates API requests, the ordering of the fields in a list is irrelevant (they all get sent in alphabetical order of the keys), so there is not a scenario being tested via adding a KVP in the middle of the list vs the end (which appears to be the only distinction between the basic->updated and updated->basic scenarios).

[NickElliot]

Suggested change

Config: testAccSecretManagerSecret_versionAliasesBasic(context),

[abheda-crest]

Okay, I've removed step 4 of this test.

[abheda-crest]

@NickElliot Could you please start the tests as it is awaiting your approval and merge this PR?

[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.

Terraform GA: Diff ( 3 files changed, 267 insertions(+))
Terraform Beta: Diff ( 3 files changed, 267 insertions(+))
TF Conversion: Diff ( 1 file changed, 17 insertions(+))

[modular-magician]

Tests analytics

Total tests: 2944
Passed tests 2641
Skipped tests: 302
Affected tests: 1

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

TestAccSecretManagerSecret_versionAliasesUpdate

Get to know how VCR tests work

[modular-magician]

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

Rerun these tests in REPLAYING mode to catch issues

$\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

[NickElliot]

LGTM!

[NickElliot]

However it needs the merge conflict resolved now, sorry for the delay that caused that

[abheda-crest]

However it needs the merge conflict resolved now, sorry for the delay that caused that

No problem, I've resolved the merge conflict. Could you please trigger the tests again and merge this PR?

[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.

Terraform GA: Diff ( 3 files changed, 267 insertions(+))
Terraform Beta: Diff ( 3 files changed, 267 insertions(+))
TF Conversion: Diff ( 1 file changed, 17 insertions(+))

Missing test report

Your PR includes resource fields which are not covered by any test.

Resource: google_secret_manager_secret (0 total tests)
Please add an acceptance test which includes these fields. The test should include the following:

resource "google_secret_manager_secret" "primary" {
  version_aliases = # value needed
}

[modular-magician]

Tests analytics

Total tests: 2945
Passed tests 2643
Skipped tests: 302
Affected tests: 0

$\textcolor{green}{\textsf{All tests passed in REPLAYING mode.}}$
View the build log

[henry-chew-partior]

Looks good, but I want to clarify: is there a scenario you're trying to test for with the 5-step update test? The situation I assume of "you can add aliases and remove them" could be covered by a simpler 3-step test like there is for annotations.

Unlike the annotations field, we cannot provide the versionAliases field while creating the secret because the version alias can only be mapped to existing versions. Hence, the first step creates a secret without this field and multiple secret versions. The second step adds this field to the resource while the subsequent steps check various update scenarios such as updating keys, updating values, updating key-value pair, adding key-value pair, and removing key-value pair. The last step removes the entire version_aliases field from the resource.

If version_alias can't be set during secrets creation, does it make more sense that the version_alias field should be implemented during creation of the secret version resource then?