Build triggers configuration in GCP - Commands & Configuration

Introduction

Build triggers automatically start a build process when you change your code. This helps you test and deploy your app without doing it manually every time.

When you want your app to build automatically after pushing code to a repository.

When you need to run tests every time someone updates the code.

When you want to deploy your app only after a successful build.

When you want to save time by automating repetitive build tasks.

When you want to keep your app updated with the latest code changes.

Config File - cloudbuild-trigger.yaml

cloudbuild-trigger.yaml

apiVersion: cloudbuild.googleapis.com/v1
kind: BuildTrigger
metadata:
  name: example-trigger
spec:
  description: Trigger build on push to main branch
  triggerTemplate:
    projectId: example-project
    repoName: example-repo
    branchName: ^main$
  build:
    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/example-project/example-app', '.']
    images:
    - 'gcr.io/example-project/example-app'

This file defines a build trigger for Google Cloud Build.

• metadata.name: The name of the trigger.
• spec.description: A short explanation of what the trigger does.
• spec.triggerTemplate: Defines which repository and branch to watch for changes.
• spec.build.steps: The steps to run when the trigger activates, here it builds a Docker image.
• spec.build.images: The Docker image to create and push.

Commands

This command creates a build trigger in Google Cloud Build using the configuration file. It tells Cloud Build to watch the specified repo and branch.

Terminal

gcloud builds triggers create cloud-source-repositories --trigger-config=cloudbuild-trigger.yaml

Expected Output

Created trigger [example-trigger].

→

--trigger-config - Specifies the YAML file that defines the build trigger.

This command lists all build triggers in your project so you can verify the trigger was created.

Terminal

gcloud builds triggers list

Expected Output

NAME             DESCRIPTION                          TRIGGER TEMPLATE

example-trigger  Trigger build on push to main branch  example-repo @ main

This command manually starts the build trigger to test if it works correctly without pushing code.

Terminal

gcloud builds triggers run example-trigger

Expected Output

Build started with ID: 12345678-1234-1234-1234-123456789abc

This command shows the most recent build to check its status and confirm the trigger ran successfully.

Terminal

gcloud builds list --limit=1

Expected Output

ID                                    STATUS    START_TIME

12345678-1234-1234-1234-123456789abc  SUCCESS   2024-06-01T12:00:00Z

→

--limit - Limits the number of builds shown to the most recent one.

Key Concept

If you remember nothing else from this pattern, remember: build triggers automate your build process by watching your code changes and starting builds automatically.

Common Mistakes

Using the wrong branch name pattern in the trigger configuration.

The trigger will not activate if the branch name does not match exactly.

Use a correct regular expression like ^main$ to match the exact branch name.

Not specifying the correct repository name in the trigger config.

Cloud Build cannot find the code to watch and will not trigger builds.

Double-check the repository name matches exactly what is in Cloud Source Repositories.

Forgetting to push code after creating the trigger to test it.

The trigger will not run automatically until a matching code change happens.

Push a commit to the watched branch or run the trigger manually to test.

Summary

Create a build trigger configuration file to define when and how builds start.

Use gcloud commands to create, list, and run build triggers.

Verify builds start automatically when code changes happen on the specified branch.

Practice

1. What is the main purpose of a build trigger in Google Cloud Build?

easy

A. To monitor server health

B. To manually deploy an application

C. To automatically start a build when code changes occur

D. To create a new repository

Solution

1. Step 1: Understand build triggers role

   Build triggers watch for code changes and start builds automatically.

2. Step 2: Compare options with purpose

   Only To automatically start a build when code changes occur describes automatic build start on code changes.

3. Final Answer:

   To automatically start a build when code changes occur -> Option C

4. Quick Check:

   Build trigger = auto build start [OK]

Hint: Build triggers start builds automatically on code changes [OK]

Common Mistakes:

• Confusing triggers with manual deployment
• Thinking triggers monitor servers
• Assuming triggers create repositories

2. Which of the following is the correct syntax to specify a branch filter in a Cloud Build trigger YAML?

easy

A. trigger:
branchName: "^main$"

B. trigger:
branchName: "main"

C. trigger:
branch: "main"

D. trigger:
branchFilter: "main"

Solution

1. Step 1: Identify correct branch filter syntax

   Cloud Build uses regex in branchName to filter branches.

2. Step 2: Match regex syntax for main branch

   "^main$" matches exactly the main branch name.

3. Final Answer:

   trigger: branchName: "^main$" -> Option A

4. Quick Check:

   branchName uses regex = trigger: branchName: "^main$" [OK]

Hint: Use regex in branchName to filter branches [OK]

Common Mistakes:

• Using branch instead of branchName
• Not using regex anchors ^ and $
• Using incorrect field like branchFilter

3. Given this trigger configuration snippet:

trigger:
  branchName: "^release-.*$"
  build:
    steps:
    - name: "gcr.io/cloud-builders/docker"
      args: ["build", "-t", "gcr.io/my-project/my-app:$SHORT_SHA", "."]

What happens when a commit is pushed to branch release-v1.2?

medium

A. The build fails due to syntax error

B. The build starts and tags the image with the commit SHA

C. The build starts but tags the image with 'latest'

D. The build does not start because branch name does not match

Solution

1. Step 1: Check branchName regex against branch

   Regex "^release-.*$" matches any branch starting with 'release-', so 'release-v1.2' matches.

2. Step 2: Understand build step and tagging

   The build uses $SHORT_SHA to tag the image, so image is tagged with commit SHA.

3. Final Answer:

   The build starts and tags the image with the commit SHA -> Option B

4. Quick Check:

   Branch matches regex and tags with SHA = The build starts and tags the image with the commit SHA [OK]

Hint: Regex matches branch, build tags image with commit SHA [OK]

Common Mistakes:

• Assuming branch does not match regex
• Thinking image tags as 'latest'
• Confusing syntax error with correct YAML

4. You configured a build trigger with this YAML snippet:

trigger:
  branchName: "main"
  build:
    steps:
    - name: "gcr.io/cloud-builders/gcloud"
      args: ["app", "deploy"]

But the build never starts when you push to main. What is the likely error?

medium

A. The build steps are missing the Docker build command

B. The trigger YAML is missing the substitutions field

C. The trigger must specify a tagName instead of branchName

D. branchName should be a regex like "^main$"

Solution

1. Step 1: Check branchName format in trigger

   Cloud Build expects branchName as a regex pattern, not plain string.

2. Step 2: Correct branchName to regex

   Changing branchName to "^main$" matches exactly the main branch and triggers build.

3. Final Answer:

   branchName should be a regex like "^main$" -> Option D

4. Quick Check:

   branchName needs regex = branchName should be a regex like "^main$" [OK]

Hint: branchName must be regex, not plain text [OK]

Common Mistakes:

• Using plain branch name without regex anchors
• Confusing branchName with tagName
• Thinking substitutions are mandatory

5. You want to create a build trigger that starts only when a tag matching v* is pushed, and the build should run two steps: first build a Docker image, then deploy it. Which YAML snippet correctly configures this trigger?

hard

A. trigger:
tagName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."]
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

B. trigger:
branchName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."]
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

C. trigger:
tagName: "v*"
build:
steps:
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

D. trigger:
tagName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:latest", "."]

Solution

1. Step 1: Identify correct tag filter syntax

   Use tagName with regex "^v.*$" to match tags starting with 'v'.

2. Step 2: Verify build steps order and commands

   First step builds Docker image tagged with $TAG_NAME, second step deploys app.

3. Step 3: Check for errors in other options

   trigger: branchName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] uses branchName instead of tagName, C misses Docker build step, D tags image as latest without deploy step.

4. Final Answer:

   trigger: tagName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] -> Option A

5. Quick Check:

   tagName regex and two steps build+deploy = trigger: tagName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] [OK]

Hint: Use tagName regex and list all build steps in order [OK]

Common Mistakes:

• Using branchName instead of tagName for tags
• Missing one of the required build steps
• Incorrect tagName regex syntax