adding user_ip_request_headers support to compute_security_policy

[felipegc]

fixes hashicorp/terraform-provider-google#15048

Adding user_ip_request_headers support to compute_security_policy

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)

compute: added `user_ip_request_headers` field to `google_compute_security_policy` resource(beta)

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I've detected that you're a community contributor. @megan07, a repository maintainer, has been assigned to assist you and help review your changes.

❓ First time contributing? Click here for more details

---

Your assigned reviewer will help review your code by:

• Ensuring it's backwards compatible, covers common error cases, etc.
• Summarizing the change into a user-facing changelog note.
• Passes tests, either our "VCR" suite, a set of presubmit tests, or with manual test runs.

You can help make sure that review is quick by running local tests and ensuring they're passing in between each push you make to your PR's branch. Also, try to leave a comment with each push you make, as pushes generally don't generate emails.

If your reviewer doesn't get back to you within a week after your most recent change, please feel free to leave a comment on the issue asking them to take a look! In the absence of a dedicated review dashboard most maintainers manage their pending reviews through email, and those will sometimes get lost in their inbox.

---

[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 ( 2 files changed, 3 insertions(+))
Terraform Beta: Diff ( 3 files changed, 54 insertions(+), 6 deletions(-))
TF Conversion: Diff ( 2 files changed, 3 insertions(+), 3 deletions(-))

[modular-magician]

Tests analytics

Total tests: 2922
Passed tests 2619
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

TestAccComputeSecurityPolicy_withAdvancedOptionsConfig

Get to know how VCR tests work

[modular-magician]

$\textcolor{green}{\textsf{Tests passed during RECORDING mode:}}$
TestAccComputeSecurityPolicy_withAdvancedOptionsConfig[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

[SarahFrench]

👋 Thanks for your PR! The test that ran above uses the GA version of the provider, not Beta, but when I ran the acceptance test manually I can see that the new field behaves well. I'm just checking internally about any gotchas around the schema.Set field type, and will resume reviewing once I've got some feedback.

[felipegc]

Hi @SarahFrench is there anything else from my side? Thanks

[SarahFrench]

Nope - I got the feedback I mentioned and I'm going to approve this in a bit. Thanks for your patience!

[SarahFrench]

When I run the Beta version of the acceptance test including the new field everything passes. I can see that ordering of the field isn't important, and there isn't any trouble when re-ordering. I remembered there was an issue with Sets but not what - it's that schema.Set has trouble with Computed values. As that's not relevant here I'm happy to approve.

[SarahFrench]

@felipegc Sorry, my delay allowed the merge conflict above to happen. I'll keep an eye on this PR and will merge it once I see it's resolved.

[felipegc]

@felipegc Sorry, my delay allowed the merge conflict above to happen. I'll keep an eye on this PR and will merge it once I see it's resolved.

I updated my branch with the upstream/main and got no conflict to solve manually. But when I ran the provider beta with my test and other test from the same file I got a message saying: “no tests to run”. Is there anything changed recently to run the acc tests locally? Thanks

[SarahFrench]

Is there anything changed recently to run the acc tests locally?

Yes - that file (resource_compute_security_policy_test.go) has been migrated into a new package by this PR. The file was previously in ./google-beta but now it's in ./google-beta/services/compute. Are you using the Makefile to run acceptance tests, or using go test ?

[zli82016]

If the tests are moved to the specific service packages, the command to run the tests needs to change. For example: make testacc TEST=./google-beta/services/compute  TESTARGS='-run=TestAccComputeAddress_withProviderDefaultLabels'

[felipegc]

Thanks @SarahFrench and @zli82016. I managed to successfully run locally with the explanation.

[SarahFrench]

Re-approving after merge conflict resolved - sorry for the confusion!