terraform-provider-google: Creation of Endpoints for Cloud Functions causes circular dependency between ESP and Endpoint services

The only thing we really need to not deploy 2 images to Cloud Run - which is the big thing messing with terraform - is the HASH in the url: https://my-cloud-run-HASH-LOC.a.run.app. If we can compute this value, or retrieve it through an API before a new image is deployed, we can make this work. We would need a data source, data.cloud_run_hash, that has as output that HASH value. The steps would be :

1. terraform calculates the hash
2. terraform deploys the endpoint with the swagger.yaml with the correct URL
3. You build and push the image with the swagger included with local-exec (as google is really saying “run this bash script”, there’s not really any way around using local-exec)
4. terraform creates the cloud run resource.

So now the problem is reduced to: how to get the HASH value?

• Does anyone know about an API that yields this value (other then deploying a dummy image)? Mentioning @chrisst as he seems to know something about the APIs.
• Is it the HASH even unique per GCP project, or is it per Cloud Run deployment?
• If these methods don’t exist, what’s the proper place to request this feature?

Also a friendly reminder to anyone coming accross this issue to +1 the original post, as it indicates the importance of the issue to the developers working on this repository.

I ran into this issue recently, and resolved it using custom domains similarly as just https://github.com/hashicorp/terraform-provider-google/issues/5528#issuecomment-953184386 mentioned.

Here is the cherry-picked code in my scripts. Note that I didn’t deploy a dummy Cloud Run service to fix the domain: deployed only the final ESPv2 instance after the Cloud Entpoints service has been deployed successfully.

resource "google_endpoints_service" "openapi_service" {
  service_name   = var.endpoint_name
  project        = var.project
  openapi_config = ...config with the custom domain decided before configuring...
}

resource "null_resource" "openapi_proxy_image" {
  triggers = {
    config_id = google_endpoints_service.openapi_service.config_id
  }

  # Script obtained from:
  # https://github.com/GoogleCloudPlatform/esp-v2/blob/master/docker/serverless/gcloud_build_image
  provisioner "local-exec" {
    command = <<EOS
      bash gcloud_build_image \
        -c ${google_endpoints_service.openapi_service.config_id} \
        -s ${var.endpoint_name} \
        -p ${var.project} \
        -v ${var.espv2_version}
    EOS
  }
}

resource "google_cloud_run_service" "endpoint" {
  template {
    spec {
      containers {
        image = format(
          "gcr.io/%s/endpoints-runtime-serverless:%s-%s-%s",
          var.project,
          var.espv2_version,
          var.endpoint_name,
          google_endpoints_service.openapi_service.config_id,
        )
        ...
      }
      ...
    }
    ...
  }
  ...
  depends_on = [null_resource.openapi_proxy_image]
}

resource "google_cloud_run_domain_mapping" "endpoint" {
  location = var.region
  name     = var.endpoint_name
  metadata {
    namespace = var.project
  }
  spec {
    route_name = google_cloud_run_service.endpoint.name
  }
}

resource "google_dns_record_set" "endpoint" {
  name         = "${var.endpoint_name}."
  managed_zone = var.dns_zone
  type         = "CNAME"
  ttl          = 300
  rrdatas      = ["ghs.googlehosted.com."]
}

Nope, there’s no step closer to a solution, and the circular dependency is still a problem. The problem is still the same: the cloud run documentation requires overwriting a previously deployed ESP container which introduces a circular dependency which terraform can’t handle.