Build triggers configuration in GCP - Step-by-Step Execution

Process Flow - Build triggers configuration

Create Trigger Config

↓

Specify Source Repo

↓

Define Event Type

↓

Set Build Steps

↓

Save Trigger

↓

Trigger Listens for Events

↓

On Event: Start Build

↓

Build Executes

↓

Build Completes

This flow shows how a build trigger is configured to listen for events in a source repository and start a build automatically.

Execution Sample

GCP

gcloud beta builds triggers create github \
  --name="my-trigger" \
  --repo-name="my-repo" \
  --repo-owner="my-owner" \
  --branch-pattern="^main$" \
  --build-config="cloudbuild.yaml"

This command creates a build trigger that starts a build when changes are pushed to the main branch of a GitHub repo.

Process Table

Step	Action	Input/Condition	Result/Output
1	Create Trigger Config	Name=my-trigger	Trigger config object created
2	Specify Source Repo	Repo=my-repo owned by my-owner	Source repository linked
3	Define Event Type	Branch pattern ^main$	Trigger listens to pushes on main branch
4	Set Build Steps	Build config file cloudbuild.yaml	Build steps defined
5	Save Trigger	All config set	Trigger saved and active
6	Trigger Listens for Events	Push event on main branch	Trigger detects event
7	On Event: Start Build	Event detected	Build process starts
8	Build Executes	Build steps run	Build runs according to config
9	Build Completes	Build finished	Build success or failure reported

💡 Build completes after executing all defined steps or fails if errors occur

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	After Step 8	Final
trigger_config	null	created with name	linked to repo	event type set	build steps set	saved and active	listening	event detected	build running	build finished

Key Moments - 3 Insights

Why does the trigger only start builds on the main branch?

Because in step 3, the branch pattern is set to '^main$', so only pushes to the main branch match and start the build (see execution_table row 3).

What happens if the build config file is missing or incorrect?

At step 8, the build executes the steps defined in the config file. If the file is missing or invalid, the build will fail (see execution_table row 8 and 9).

Does the trigger start builds for pull requests automatically?

No, unless the event type is configured to listen for pull request events. Here, only push events on the main branch are configured (see execution_table row 3).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the trigger saved and becomes active?

A Step 5

B Step 3

C Step 7

D Step 9

💡 Hint

Check the 'Result/Output' column for when the trigger is 'saved and active' (row 5).

According to the variable tracker, what is the state of 'trigger_config' after step 4?

A Created with name

B Linked to repo

C Build steps set

D Event detected

💡 Hint

Look at the 'After Step 4' column for 'trigger_config' in variable_tracker.

If the branch pattern was changed to '^dev$', when would the trigger start builds?

A On pushes to the main branch

B On pushes to the dev branch

C On pushes to any branch

D On pull requests only

💡 Hint

Refer to execution_table row 3 about branch pattern matching.

Concept Snapshot

Build triggers listen for events in source repos.
Configure with name, repo, event type (e.g., branch pattern), and build steps.
Trigger activates after saving.
Starts builds automatically on matching events.
Build steps run as defined in config file.

Full Transcript

This visual execution shows how to configure a build trigger in Google Cloud Platform. First, a trigger configuration is created with a name. Then, the source repository is specified by name and owner. Next, the event type is defined, such as listening for pushes to the main branch. Build steps are set using a build configuration file. After saving, the trigger becomes active and listens for events. When a matching event occurs, the trigger starts the build process, which executes the defined steps. The build completes with success or failure. Variables like the trigger configuration change state at each step, from creation to active listening to build running and finishing. Key points include understanding branch pattern matching, the importance of the build config file, and event types that start builds. The quiz tests knowledge of trigger saving, variable states, and event matching.

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