googlecloudplatform / solutions-terraform-cloudbuild-gitops Goto Github PK

As a good practice, the terraform.tfvars files should not be committed to source control.

In that case the CI/CD breaks, as the files are needed in the terraform init step. What would be a good strategy to avoid adding the terraform.tfvars files to source control without breaking the Cloud Build pipeline?

Currently this repo only works with legacy Terraform 0.11.x versions, it should be updated for Terraform 0.12.x.

https://cloud.google.com/compute/docs/images/os-details#debian

Shouldn't it be written something like the following?

output "subnet" {
  value = "${element(module.vpc.subnets, 0).subnet_name}"
}

Currently in this repository I see the following branches:

• dev (as default)
• master
• prod

To my understanding on a strategy where we have on env per branch, we make a change on dev, if everything if fine we then create a PR promoting changes to next env, in this case prod.

1. In this case why we have master ? What purpose does it serve in the workflow?

2. Besides that I'm curious in this approach:
   How we update a value in terraform.tfvars for prod?
   Because if we need to keep branches in sync to promoted changes I guess we cannot directly commit to prod. Instead my assumption is that even if we change just a value to prod we have to actually submit it to dev and "promote" it with a PR to prod so the branches remain in sync. Is my assumption correct?