Add Cloud Build for GCP CI env #58
Conversation
roger2hk
force-pushed
the
gcp-cloudbuild
branch
from
147bbc1 to
48b92b1
Compare
| locals { | ||
| env = path_relative_to_include() | ||
| project_id = get_env("GOOGLE_PROJECT", "transparency-dev") | ||
| location = get_env("GOOGLE_REGION", "us-central1") |
There was a problem hiding this comment.
very nit, region to align with tessera repo
There was a problem hiding this comment.
Do you mean the location cannot be changed?
There was a problem hiding this comment.
I mean that this local / variable is called "region" instead of "location" in the tessera repo, we might as well use the same. I think that one spanner label also have a different name. Nothing too important.
There was a problem hiding this comment.
I see. They seem to be interchangeable. Most terraform resources use location as the arguments.
| resource "google_service_account" "cloudbuild_service_account" { | ||
| account_id = "cloudbuild-${var.env}-sa" | ||
| display_name = "Service Account for Cloud Build (${var.env})" | ||
| } | ||
|
|
||
| resource "google_project_iam_member" "logging_log_writer" { | ||
| project = var.project_id | ||
| role = "roles/logging.logWriter" | ||
| member = "serviceAccount:${google_service_account.cloudbuild_service_account.email}" | ||
| } | ||
|
|
||
| resource "google_artifact_registry_repository_iam_member" "artifactregistry_writer" { | ||
| project = google_artifact_registry_repository.docker.project | ||
| location = google_artifact_registry_repository.docker.location | ||
| repository = google_artifact_registry_repository.docker.name | ||
| role = "roles/artifactregistry.writer" | ||
| member = "serviceAccount:${google_service_account.cloudbuild_service_account.email}" | ||
| } | ||
|
|
||
| # TODO: Use google_cloud_run_service_iam_member to limit the service scope. | ||
| resource "google_project_iam_member" "run_developer" { | ||
| project = var.project_id | ||
| role = "roles/run.developer" | ||
| member = "serviceAccount:${google_service_account.cloudbuild_service_account.email}" | ||
| } | ||
|
|
||
| resource "google_project_iam_member" "iam_service_account_user" { | ||
| project = var.project_id | ||
| role = "roles/iam.serviceAccountUser" | ||
| member = "serviceAccount:${google_service_account.cloudbuild_service_account.email}" | ||
| } |
There was a problem hiding this comment.
I think this all defined in overground, no need to define this here.
There was a problem hiding this comment.
They're useful when setting up the cloud build in other GCP projects. I'm inclined to keep these. Perhaps we can use conditional IAM resources creation or provide the terraform import command.
| resource "google_project_iam_member" "run_service_agent" { | ||
| project = var.project_id | ||
| role = "roles/run.serviceAgent" | ||
| member = "serviceAccount:${google_service_account.cloudrun_service_account.email}" | ||
| } | ||
|
|
There was a problem hiding this comment.
Same here, and for the other membership below actually (I had missed this in a previous PR). I don't think they should live here, but in Overground rather. Then, terraform can add biding to the GCS and Spanner resources for the right users to have the right roles on these resources. Let's clean that all up in a followup PR?
Or one could argue that we want to leave them around for transparency and to show to the world what's our IAM structure, at the cost of having two sources for this... TBD speaking with the team I'd say.
There was a problem hiding this comment.
Sure, let's talk about this with the team.
| locals { | ||
| env = path_relative_to_include() | ||
| project_id = get_env("GOOGLE_PROJECT", "transparency-dev") | ||
| location = get_env("GOOGLE_REGION", "us-central1") |
There was a problem hiding this comment.
I mean that this local / variable is called "region" instead of "location" in the tessera repo, we might as well use the same. I think that one spanner label also have a different name. Nothing too important.
Towards #53