CD for google cloud functions using google cloud repository - how to automate deployment?

Question

I am new to GCP however did some read up of docs regarding deploying from google cloud repo https://cloud.google.com/functions/docs/deploying/repo

however I stil miss some automation bit

to don't have call by myself the gcloud functions deploy locally rather delegate it to google cloud repo (smth similar to gitlab-ci does) to handle it after new changes pushed to certain branch.

The most desired scenario having something like .gitlab-ci yaml in my cloud functions repo which takes care of setup the cloud functions and linking it to certain dirs in repo.

Answer 1

As mentioned in the Documentation :

Continuous Integration and Deployment (CI/CD) pipelines help to ensure that your functions work both locally and in a test environment on Google Cloud. Once you finish developing locally, you can configure a CI/CD platform such as Cloud Build to run your existing Cloud Functions tests on an ongoing basis. Continuous testing helps ensure that your code continues to work as intended and that your dependencies remain up-to-date. As Cloud Functions are not updated automatically, you can also configure CI/CD pipelines (including those built on top of Cloud Build) to automatically test and redeploy your functions from a source repository such as GitHub, Bitbucket, or Cloud Source Repositories.

You can also refer to the Article and blog for a brief description of the CI\CD for GCP Serverless Cloud Functions. You can also refer to the Thread which explains the brief aspect of CI/CD Pipeline for cloud functions and how it works to resolve issue of re deployment as:

The CICD uses Terraform inside Cloud Build ( cloud build yaml file contains 'terraform init' and terraform apply'). Thus, push (or pull request) triggers a Cloud Build job, which executes Terraform.

When the Terraform is triggered, the zip file is created in case the cloud function code has been modified. The SHA hash code of the zip file is different (if the code has been modified). Thus, the local variable with the GCS object name gets a different value. It means that the zip file is uploaded to the GCS bucket with the new name. As the source code object has now a new name source_archive_object = google_storage_bucket_object.cf_source_zip.name, terraform finds out that the cloud function has to be redeployed (because the state file has the old name of the archive object). The cloud function is redeployed. On the other hand, if the code is not modified - the name source_archive_object = google_storage_bucket_object.cf_source_zip.name is not modified, so Terraform does not deploy anything.