terraform GCP cloud function without having to deploy via terraform in CI or breaking past deployments when running locally?

Question

I have some working terraform definitions among a larger project:

resource "google_storage_bucket" "owlee_functions_bucket" {
  name     = "owlee_functions_bucket"
  location = "europe-west2"
  project  = "owlee-software"
}

resource "google_storage_bucket_object" "archive" {
  name   = "index.zip"
  bucket = google_storage_bucket.owlee_functions_bucket.name
  source = "../apps/backend/dist/index.zip"
}

resource "google_cloudfunctions_function" "backend_function" {
  name    = "backend_function"
  runtime = "nodejs16"
  project = "owlee-software"
  region  = "europe-west2"

  available_memory_mb   = 128
  source_archive_bucket = google_storage_bucket.owlee_functions_bucket.name
  source_archive_object = google_storage_bucket_object.archive.name
  trigger_http          = true
  entry_point           = "OWLEE"
}

Then I'm trying to deploy via CI, for now, I'm just running terraform apply after zipping up the new version of the function to handle deployment.

It's not great and I'd like to change that to a non-terraform process ideally but that doesn't seem to be documented/possible anywhere which makes me think I have the wrong approach with this.

The second issue which is more urgent to solve --

I want to continue managing my infrastructure locally for now and do not want to have to zip up a new version of the function to deploy everytime I have to run terraform apply locally.

Is there a way -- after its creation -- to avoid overwriting/uploading the function via terraform?

I'm guessing this would be somewhat necessary for the CI deployment to work anyway.

I've looked at a handful of other SO threads but they were looking at specifics around cloud-build and the artifacts registry.

Answer 1

我建议您通过 terraform 部署云功能，但云功能的 CI 由云构建（也由 terraform 创建）维护我认为这是最合乎逻辑的解决方案，因为 terraform 管理基础设施而不是云功能的实现.

Answer 2

Instead of using a fixed name as you are, use a random string or depending on needs the commit hash for example. This can be prefixed with other things to make it even more unique.

resource "random_string" "function" {
  length           = 8
  special          = false
  
  keepers = {
    commit_hash = var.commit_hash,
    environment = var.environment,
  }
}

resource "google_storage_bucket_object" "archive" {
  name   = "index.zip"
  bucket = google_storage_bucket.owlee_functions_bucket.name
  source = "../apps/backend/dist/${random_string.function.result}.zip"
}

resource "google_cloudfunctions_function" "backend_function" {
  name    = "backend_function"
  runtime = "nodejs16"
  project = "owlee-software"
  region  = "europe-west2"

  available_memory_mb   = 128
  source_archive_bucket = google_storage_bucket.owlee_functions_bucket.name
  source_archive_object = google_storage_bucket_object.archive.name
  trigger_http          = true
  entry_point           = "OWLEE"
}

This way if you provide an environ.net such as prod and the same commit hash every time, it will create the same zip file.

If you provide a new environment , say "local", it will generate a new zip. You can then create multiple instances of functions or make more changes to the google_cloudfunctions_function so that it can be used with workspaces