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.
