feat: Infrastructure Manager workspace blueprint #271
Conversation
This blueprint creates an opinionated workflow for actuating Terraform resources using Infrastructure Manager using GitHub/GitLab and Cloud Build.
modules/im_cloudbuild_workspace/templates/create-preview.sh.tftpl
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| provider_meta "google" { | ||
| module_name = "blueprints/terraform/terraform-google-bootstrap:tf_cloudbuild_workspace/v7.0.0" |
There was a problem hiding this comment.
| module_name = "blueprints/terraform/terraform-google-bootstrap:tf_cloudbuild_workspace/v7.0.0" | |
| module_name = "blueprints/terraform/terraform-google-bootstrap:im_cloudbuild_workspace/v7.0.0" |
There was a problem hiding this comment.
Updated, although is there any issues with any versioning here given this is unreleased at the moment?
There was a problem hiding this comment.
The versioning should be okay, our release tooling should bump the version string in next release PR
test/integration/im_cloudbuild_workspace_github/im_cloudbuild_workspace_github_test.go
Outdated
Show resolved
Hide resolved
build/int.cloudbuild.yaml
Outdated
| secretEnv: ['IM_GITHUB_PAT'] | ||
| env: | ||
| - 'TF_VAR_im_github_pat_secret=$_IM_GITHUB_PAT_SECRET_ID' |
There was a problem hiding this comment.
nit: I think this is unnecessary
There was a problem hiding this comment.
Currently following the example here which sets up a similar secret to be used here https://github.com/GoogleCloudPlatform/terraform-google-tf-cloud-agents/blob/main/build/int.cloudbuild.yaml#L156.
Would the TF_VAR setup be preferred instead? I think I'd need to add the variable to the variables.tf in the setup folder? And then update the YAML and example to use that accordingly?
Currently, it sets the ENV variable using that secret which is used by the integration test file which sets the variable used by the example.
There was a problem hiding this comment.
In this case it was just a nit that this init step wont care about the env var so we could skip it
Example and minimum version set to the minimum IM version.
Prevents issue with creating multiple triggers for a repository (maybe dependent upon different branches).
Trims the top line and counts how many lines are present. Should only be 1 line corresponding to a single deployment.
Was previously added to be used by the integration test, replaced with hard-coded values.
Following better practices for IAM resources
* Style issues * Removed explicit trigger name checks as those have random IDs added. The IDs are used directly for checking if they ran, so still checking that behavior * Added clean up step to clean up the old deployment rather than leaving it for project clean up
Currently using the secret manager setup
Utilizes the GitHub API to create a repository on demand, and delete it after teardown.
Head branch was pushed to by a user without write access
Hitting some IAM propagation errors otherwise
The PAT currently needs different rights set up in order to do so, but it should work with an existing repository.
This reverts commit 0748ad6.
Should help deal with IAM propagation delay, similar to the other service accounts being checked for a specific role.
They don't contain sensitive values themselves, and might just be the linter reacting to the variable names. But I could see why a secret_id might want to be labeled as sensitive as well.
This blueprint creates an opinionated workflow for actuating Terraform resources using Infrastructure Manager using GitHub/GitLab and Cloud Build.