Cloud Build Triggers and CI/CD

Cloud Build triggers are event-driven mechanisms that automatically initiate a build process in Google Cloud Build. They eliminate manual intervention by starting a build when a specified event occurs in a connected source repository (Cloud Source Repositories, GitHub, or Bitbucket). Triggers are the foundation of CI/CD pipelines in GCP, enabling continuous integration and continuous delivery.

Without triggers, developers must manually start builds via gcloud builds submit or the Cloud Console. This is error-prone and slow. Triggers automate the build process, ensuring that every code change is built, tested, and deployed consistently. They enforce standards, reduce human error, and accelerate release cycles.

A Cloud Build trigger is defined by: - Source repository: The repo that contains the source code and build configuration. - Event: What triggers the build (e.g., push to a branch, new tag, pull request). - Build configuration: Either an inline build config or a cloudbuild.yaml file in the repo. - Substitutions: Variables that customize the build per trigger. - Service account: The identity used by Cloud Build to execute the build.

When an event occurs (e.g., a git push to a branch), the source repository sends a webhook to Cloud Build. Cloud Build validates the event against the trigger's criteria (e.g., branch regex). If it matches, Cloud Build creates a build resource and assigns a unique build ID. The build then runs according to the steps defined in the build configuration. Cloud Build pulls a builder image (e.g., gcr.io/cloud-builders/gcloud) for each step, executes the command, and stores artifacts (e.g., container images) in Container Registry or Artifact Registry. Build logs are streamed to Cloud Logging and can be viewed in the Cloud Console.

The build configuration defines the steps Cloud Build executes. Example:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/my-image']
- name: 'gcr.io/cloud-builders/gke-deploy'
  args:
  - 'run'
  - '--filename=deployment.yaml'
  - '--image=gcr.io/$PROJECT_ID/my-image'
  - '--location=us-central1'
  - '--cluster=my-cluster'

Default values: timeout is 10 minutes per step, overall build timeout is 1 hour (configurable up to 24 hours). Each step runs in a separate container. Steps run sequentially unless you use waitFor: ['-'] to run in parallel.

Substitutions are variables you can use in the build config. Default substitutions include: - $PROJECT_ID: GCP project ID. - $BUILD_ID: Unique build ID. - $REPO_NAME: Name of the source repo. - $BRANCH_NAME: Branch name (for push triggers). - $TAG_NAME: Tag name (for tag triggers). - $SHORT_SHA: Short SHA of the commit.

You can also define custom substitutions in the trigger configuration. For example:

substitutions:
  _DEPLOY_REGION: us-central1

Then reference it as $_DEPLOY_REGION in the build config.

To create and manage triggers, you need: - cloudbuild.triggers.create - cloudbuild.triggers.get - cloudbuild.triggers.list - cloudbuild.triggers.update - cloudbuild.triggers.delete - cloudbuild.triggers.run

Predefined roles: Cloud Build Editor (roles/cloudbuild.builds.editor) includes trigger permissions. For builds, the service account used (default or custom) needs permissions to push images, deploy, etc.

Cloud Source Repositories (CSR) require no additional webhook configuration. For GitHub or Bitbucket, you must connect the repository via Cloud Build's repository connection (using Cloud Build App for GitHub). Once connected, Cloud Build sets up webhooks automatically. For GitHub, you need to install the Google Cloud Build app and grant permissions. For Bitbucket, you use a workspace connection.

Cloud Build can publish build status updates to Pub/Sub. You can set up a Pub/Sub trigger to start another build based on a successful build. This is useful for multi-step pipelines (e.g., build image -> trigger deployment build). However, this is different from source event triggers.

List triggers:

gcloud builds triggers list --project=my-project

Describe a trigger:

gcloud builds triggers describe my-trigger --region=us-central1

Run a trigger manually:

gcloud builds triggers run my-trigger --branch=main

Create a push trigger from command line:

gcloud builds triggers create push --name=my-push-trigger \
  --repo=https://source.developers.google.com/p/my-project/r/my-repo \
  --branch-pattern=^main$ \
  --build-config=cloudbuild.yaml

Create a scheduled trigger:

gcloud builds triggers create scheduled --name=nightly-build \
  --schedule="0 2 * * *" \
  --timezone="America/New_York" \
  --build-config=cloudbuild.yaml

A large e-commerce company uses Cloud Build triggers to automate deployments across dev, staging, and production environments. They have three branches: dev, staging, and main. Each branch has a push trigger that builds the code and deploys to the corresponding GKE cluster. The main branch trigger also runs integration tests and requires manual approval via Cloud Build approvals (Enterprise feature). They use substitutions for environment-specific variables (e.g., _CLUSTER_NAME). Common scale: 50+ developers pushing 200+ commits daily. Performance considerations: Build time averages 8 minutes; they use Kaniko cache for faster Docker builds. Misconfiguration: A developer accidentally pushed a breaking change to main that bypassed staging due to a misconfigured branch regex (allowed main and master both). They fixed it by tightening the regex to ^main$ and adding a staging gate.

A financial services firm must run nightly builds of their core banking application to ensure compliance with regulatory requirements. They use a scheduled trigger that runs at 2:00 AM EST every day. The build runs static code analysis, unit tests, and generates a compliance report. The report is stored in Cloud Storage and sent to auditors. They use Cloud Scheduler to trigger the build. Performance: The build takes 45 minutes; they increased the timeout to 2 hours. Misconfiguration: The cron expression was 0 2 * * * but the timezone was set to UTC, so builds ran at 2:00 AM UTC (9:00 PM EST). They corrected the timezone to America/New_York.

An open-source project hosted on GitHub uses Cloud Build triggers to validate pull requests. When a PR is created or updated, a trigger runs unit tests and linting. The trigger uses a pull request event and only runs on PRs from the main repo (not forks) for security. The build status is reported back to GitHub via the Cloud Build GitHub app. Common scale: 100+ PRs per week. Performance: Builds complete in under 5 minutes. Misconfiguration: A contributor from a forked repo expected their PR to trigger a build, but it didn't. They learned that PRs from forks are disabled by default. The project maintainer enabled 'Allow pull request builds from forked repositories' in the trigger settings.