fix: module seed_bootstrap now waiting on module required_groups

[lpezet]

This is a fix for #1272

[google-cla[bot]]

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.

[lpezet]

I tried to run the integration tests but I got this error like a couple minutes in:

│ Error: Request `Enable Project Service "sourcerepo.googleapis.com" for project "ci-foundation-zex7ux-5w89"` returned error: Batch request and retried single request "Enable Project Service \"sourcerepo.googleapis.com\" for project \"ci-foundation-zex7ux-5w89\"" both failed. Final error: failed to enable services: failed on request preconditions: googleapi: Error 403: Permission denied to enable service [sourcerepo.googleapis.com]
│ Help Token: AbBK4NqG5AcVXitpIUj7UK_72H2QlQp-kliqANjF4TzkMKUBQeOdFrOJbW-vTKuuDp54lt84e-fnPkL0_YeIOR86fbUrU5TaGBQMyaSQWSxGlhmx
│ Details:
│ [
│   {
│     "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
│     "violations": [
│       {
│         "subject": "?error_code=110002\u0026service=servicemanagement.googleapis.com\u0026permission=servicemanagement.services.bind\u0026resource=ci-foundation-zex7ux-5w89",
│         "type": "googleapis.com"
│       }
│     ]
│   },
│   {
│     "@type": "type.googleapis.com/google.rpc.ErrorInfo",
│     "domain": "serviceusage.googleapis.com",
│     "metadata": {
│       "permission": "servicemanagement.services.bind",
│       "resource": "ci-foundation-zex7ux-5w89",
│       "service": "servicemanagement.googleapis.com"
│     },
│     "reason": "AUTH_PERMISSION_DENIED"
│   }
│ ]
│ , forbidden
│ 
│   with module.project.module.project-factory.module.project_services.google_project_service.project_services["sourcerepo.googleapis.com"],
│   on .terraform/modules/project/modules/project_services/main.tf line 31, in resource "google_project_service" "project_services":
│   31: resource "google_project_service" "project_services" {
│ 
╵

If someone could help me out with that one, I'd appreciate, so I can run tests on my end first.

[eeaton]

Error: Request Enable Project Service "sourcerepo.googleapis.com" for project "ci-foundation-zex7ux-5w89" returned error

Looks like you've bumped into the deprecation of CSR: https://cloud.google.com/source-repositories/docs. Existing customer organizations can continue to use CSR, but new organizations who have never used CSR prior to June 17 2024 cannot start using it.

We're in the process of replacing it and repositioning one of the other methods as the default deployment option (see #1249), but in the meantime you should be able to use the Github, Gitlab, or local deployment options.

[lpezet]

in the meantime you should be able to use the Github, Gitlab, or local deployment options.

I'm just running make docker_test_prepare as per CONTRIBUTING.md. How do I go about using Github for example to prepare and run tests then?

[lpezet]

Note that there's no "s" at the end of the module name: module.required_groups --> module.required_group

Sorry! Just fixed it.

[eeaton]

I'm just running make docker_test_prepare as per CONTRIBUTING.md.

I see, looks like the test framework we use from the upstream CFT provider also has a dependency on Cloud Source Repositories. I'll add this to our backlog that we need to address the CSR deprecation for the docker tests as well. (For the record, I was referring to the deployment guidance here

Contributing.md has the same guidance for all repos that use CFT, but in this repo's case, because the foundation is so large and complex it's less practical. Many open source blueprints using CFT are a single project or two, so it's reasonable to ask contributors to create the entire repo as part of the tests, but in this case the time and effort to run all the tests in contributing.md can be disproportional.

My practical advice for working with this repo, particularly for making small changes: just run the make docker_generate_docs and make docker_test_lint . This will catch the obvious changes like referencing a non-existent variable. Then after you make a PR, there are mandatory CI tests run on our side to automatically create all the resources and run the full suite of tests against them.

[apeabody]

I'm just running make docker_test_prepare as per CONTRIBUTING.md.

I see, looks like the test framework we use from the upstream CFT provider also has a dependency on Cloud Source Repositories. I'll add this to our backlog that we need to address the CSR deprecation for the docker tests as well. (For the record, I was referring to the deployment guidance here

Contributing.md has the same guidance for all repos that use CFT, but in this repo's case, because the foundation is so large and complex it's less practical. Many open source blueprints using CFT are a single project or two, so it's reasonable to ask contributors to create the entire repo as part of the tests, but in this case the time and effort to run all the tests in contributing.md can be disproportional.

My practical advice for working with this repo, particularly for making small changes: just run the make docker_generate_docs and make docker_test_lint . This will catch the obvious changes like referencing a non-existent variable. Then after you make a PR, there are mandatory CI tests run on our side to automatically create all the resources and run the full suite of tests against them.

Hi @eeaton - I suspect (without seeing diagnostic output) that the make docker_test_prepare dependency on Cloud Source Repositories is due to the sourcerepo API activation in this repo's test/setup: https://github.com/terraform-google-modules/terraform-example-foundation/blob/master/test/setup/main.tf#L65C6-L65C16

That line could likely be commented out to verify or if not using Cloud Source Repositories.

[eeaton]

ACK thanks for the tip Andrew. I'll merge and close this PR, but add your comment about the likely CSR culprit to the tracking issue to replace CSR