add enterprise_config_resource_name to resource google_cloudbuild_trigger (#9956)

[wilsonfv]

fixes hashicorp/terraform-provider-google#9956

Cloud Build offers integration with Private Github Enterprise

The steps from initial configuration setup to a build trigger are like

1. create host connection with private Github Enterprise
2. connect to repository on private Github Enterprise
3. create build trigger on repository

As of now, step 1 and 2 could only done manually as described on this ticket integrations/terraform-provider-github#509

Assuming step 1 and 2 have been completed, existing resource google_cloudbuild_trigger (terraform-google-provider v4.44.1) does not support GitHubEnterpriseConfig while current Cloud Build Trigger Rest API does support enterpriseConfigResourceName, so this PR is to address the gap between terraform resource and Cloud Build API.

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).
• Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
• 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).
• Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

cloudbuild: added support for `"enterpriseConfigResourceName"` in `google_cloudbuild_trigger`

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[modular-magician]

Oops! It looks like you're using an unknown release-note type in your changelog entries:

• REPLACEME

Please only use the types listed in https://github.com/GoogleCloudPlatform/magic-modules/blob/master/.ci/RELEASE_NOTES_GUIDE.md.

[modular-magician]

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

I've detected that you're a community contributor. @roaks3, 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, 28 insertions(+))
Terraform Beta: Diff ( 2 files changed, 28 insertions(+))
TF Validator: Diff ( 3 files changed, 14 insertions(+), 3 deletions(-))

[modular-magician]

Tests analytics

Total tests: 2281
Passed tests 2035
Skipped tests: 244
Failed tests: 2

Action taken

Triggering VCR tests in RECORDING mode for the tests that failed during VCR. Click here to see the failed tests

TestAccLoggingBucketConfigProject_cmekSettings|TestAccFirebaserulesRelease_BasicRelease

[modular-magician]

Tests passed during RECORDING mode:
TestAccLoggingBucketConfigProject_cmekSettings[Debug log]
TestAccFirebaserulesRelease_BasicRelease[Debug log]

All tests passed
View the build log or the debug log for each test

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

[modular-magician]

Tests analytics

Total tests: 2281
Passed tests 2036
Skipped tests: 244
Failed tests: 1

Action taken

Triggering VCR tests in RECORDING mode for the tests that failed during VCR. Click here to see the failed tests

TestAccLoggingBucketConfigProject_cmekSettings

[modular-magician]

Tests passed during RECORDING mode:
TestAccLoggingBucketConfigProject_cmekSettings[Debug log]

All tests passed
View the build log or the debug log for each test

[roaks3]

LGTM, but could you add this field to a test in mmv1/third_party/terraform/tests/resource_cloudbuild_trigger_test.go? Specifically, I think we'd like this to be tested with an update scenario, because if the field is immutable, the test would fail and input: true would be needed.

[wilsonfv]

LGTM, but could you add this field to a test in mmv1/third_party/terraform/tests/resource_cloudbuild_trigger_test.go? Specifically, I think we'd like this to be tested with an update scenario, because if the field is immutable, the test would fail and input: true would be needed.

Hi @roaks3
I dont think I could write any test against this changes.

Reason being:

enterpriseConfigResourceName is a mutable property inside Cloud Build Trigger. i.e. during a terraform provision of resource google_cloudbuild_trigger, we can update / remove enterprise_config_resource_name. That being said, changing value of enterprise_config_resource_name in google_cloudbuild_trigger will re-point the trigger to another self-hosted github enterprise while removing enterprise_config_resource_name from google_cloudbuild_trigger will re-point the trigger from self-hosted github enterprise to the public github.com.

existing terraform github example cloudbuild_trigger_github.tf.erb does not have any acceptance test (see terraform.yaml and resource_cloudbuild_trigger_test.go). I believe it's because Cloud Build Trigger acceptance test with github will require dependency on public github.com or self-hosted github enterprise which are not possible to implement

Let me know your thoughts

[roaks3]

@wilsonfv I had been waiting on Riley's comment #6563 (review) to see where we landed on testing this, but it looks like we've relaxed that requirement. #7236 was merged recently, which is essentially the same change that you had suggested.

Sorry for the delay on this, and that this PR ended up being superseded.

Closing as the underlying issue is now resolved.