Cloud Build for CI/CD in GCP - Commands & Configuration

Introduction

Cloud Build helps you automatically build and test your code when you make changes. It solves the problem of manually running tests and deployments by automating these steps in a safe and repeatable way.

When you want to automatically test your code every time you save changes.

When you want to build and deploy your app without doing it by hand.

When you want to make sure your app works the same way every time you update it.

When you want to share your build process with your team so everyone uses the same steps.

When you want to connect your code repository to a cloud service that runs your builds.

Config File - cloudbuild.yaml

cloudbuild.yaml

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-app', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/my-project/my-app']
images:
- 'gcr.io/my-project/my-app'

This file tells Cloud Build what to do step-by-step.

steps: Each step runs a container to do a task. Here, the first step builds a Docker image from your app code. The second step pushes that image to Google Container Registry.

images: This lists the images that Cloud Build will create and store.

Commands

This command sends your code and the cloudbuild.yaml file to Cloud Build. It starts the build process defined in the file.

Terminal

gcloud builds submit --config cloudbuild.yaml .

Expected Output

Creating temporary tarball archive of 5 files before upload...

Uploading tarball of [.] to [gs://my-project_cloudbuild/source/...]...

Created [https://console.cloud.google.com/cloud-build/builds/12345678-1234-1234-1234-123456789abc?project=my-project].

Logs are available at [https://console.cloud.google.com/cloud-build/builds/12345678-1234-1234-1234-123456789abc?project=my-project].

→

--config - Specifies the build configuration file to use.

This command shows the last three builds that ran in your project. It helps you check if your build succeeded or failed.

Terminal

gcloud builds list --limit=3

Expected Output

ID                                    STATUS    START_TIME                 DURATION

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

87654321-4321-4321-4321-cba987654321 FAILURE   2024-05-31T15:00:00Z      1m10s

abcdef12-3456-7890-abcd-ef1234567890 SUCCESS   2024-05-30T09:00:00Z      3m5s

→

--limit - Limits the number of builds shown.

This command shows detailed information about a specific build, including logs and status.

Terminal

gcloud builds describe 12345678-1234-1234-1234-123456789abc

Expected Output

id: 12345678-1234-1234-1234-123456789abc

status: SUCCESS

createTime: '2024-06-01T12:00:00Z'

steps:

- name: 'gcr.io/cloud-builders/docker'

  args: ['build', '-t', 'gcr.io/my-project/my-app', '.']

  status: SUCCESS

- name: 'gcr.io/cloud-builders/docker'

  args: ['push', 'gcr.io/my-project/my-app']

  status: SUCCESS

images:

- 'gcr.io/my-project/my-app'

Key Concept

If you remember nothing else from this pattern, remember: Cloud Build runs your build steps automatically so you don't have to do them by hand.

Common Mistakes

Not specifying the correct build config file with --config flag.

Cloud Build will use the default config or fail if it can't find one, causing your build to not run as expected.

Always use --config cloudbuild.yaml to point to your build steps file.

Not checking build status after submitting the build.

You might think your build succeeded but it could have failed, causing deployment issues later.

Use gcloud builds list and gcloud builds describe to verify build success.

Summary

Create a cloudbuild.yaml file to define your build steps.

Run gcloud builds submit with the config file to start the build.

Check recent builds with gcloud builds list to see their status.

Use gcloud builds describe to get detailed info about a specific build.

Practice

1. What is the primary purpose of Google Cloud Build in a CI/CD pipeline?

easy

A. To store large amounts of data

B. To automate building, testing, and deploying code

C. To monitor network traffic

D. To manage user permissions

Solution

1. Step 1: Understand Cloud Build's role

   Cloud Build automates the process of building, testing, and deploying code, which is essential in CI/CD pipelines.

2. Step 2: Eliminate unrelated options

   Storing data, monitoring network traffic, and managing permissions are not primary functions of Cloud Build.

3. Final Answer:

   To automate building, testing, and deploying code -> Option B

4. Quick Check:

   Cloud Build = Automate build/test/deploy [OK]

Hint: Remember: Cloud Build automates code delivery steps [OK]

Common Mistakes:

• Confusing Cloud Build with storage services
• Thinking Cloud Build manages network or permissions
• Assuming Cloud Build only builds code without testing or deploying

2. Which of the following is the correct way to specify a build step in a Cloud Build YAML file?

easy

A. actions:
- image: 'docker'
run: ['build', '-t', 'image', '.']

B. build_steps:
- container: 'gcr.io/cloud-builders/docker'
commands: ['build', '-t', 'image', '.']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']

D. commands:
- use: 'docker'
execute: ['build', '-t', 'image', '.']

Solution

1. Step 1: Review Cloud Build YAML syntax

   The correct key for build steps is 'steps', and each step uses 'name' for the builder image and 'args' for commands.

2. Step 2: Compare options to syntax

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] matches the correct syntax. Other options use incorrect keys like 'build_steps', 'actions', or 'commands'.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] -> Option C

4. Quick Check:

   Use 'steps' with 'name' and 'args' in Cloud Build YAML [OK]

Hint: Look for 'steps' with 'name' and 'args' keys in YAML [OK]

Common Mistakes:

• Using wrong keys like 'build_steps' or 'actions'
• Confusing 'args' with 'commands'
• Omitting the builder image name

3. Given this Cloud Build YAML snippet, what will be the output of the build step?

steps:
- name: 'ubuntu'
  args: ['echo', 'Hello, Cloud Build!']

medium

A. Build fails due to missing Docker image

B. Syntax error in YAML file

C. No output is produced

D. Hello, Cloud Build!

Solution

1. Step 1: Analyze the build step

   The step uses the 'ubuntu' image and runs the command 'echo Hello, Cloud Build!'. This command prints the message to the output.

2. Step 2: Determine expected output

   Since 'echo' prints text, the output will be 'Hello, Cloud Build!'. There is no syntax error or missing image because 'ubuntu' is a valid public image.

3. Final Answer:

   Hello, Cloud Build! -> Option D

4. Quick Check:

   Echo command prints text output [OK]

Hint: Echo commands print their arguments as output [OK]

Common Mistakes:

• Assuming build fails due to image name
• Thinking no output is produced by echo
• Confusing YAML syntax errors with valid syntax

4. You wrote this Cloud Build YAML but the build fails immediately. What is the error?

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image']

medium

A. Missing the build context (dot) at the end of args

B. Incorrect builder image name

C. YAML indentation error

D. args should be a string, not a list

Solution

1. Step 1: Check Docker build command syntax

   The Docker build command requires a build context, usually '.' at the end, to specify where to find the Dockerfile.

2. Step 2: Identify missing argument

   The args list misses the '.' context argument, causing the build to fail immediately.

3. Final Answer:

   Missing the build context (dot) at the end of args -> Option A

4. Quick Check:

   Docker build needs context path '.' [OK]

Hint: Always end docker build args with '.' for context [OK]

Common Mistakes:

• Assuming image name is wrong
• Thinking YAML indentation is the issue
• Using string instead of list for args

5. You want to create a Cloud Build pipeline that builds a Docker image, runs tests, and then deploys only if tests pass. Which YAML structure correctly represents this workflow?

hard

A. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

B. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

D. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

Solution

1. Step 1: Understand step dependencies in Cloud Build

   Cloud Build starts steps in parallel by default. Use 'waitFor: ["-"]' to make a step wait for all previous steps to succeed.

2. Step 2: Analyze options for correct workflow

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] in steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] ensures tests wait for build, and deploy waits for both.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] -> Option A

4. Quick Check:

   waitFor ['-'] on test and deploy enforces build -> test -> deploy [OK]

Hint: Use waitFor: ['-'] on test and deploy steps for sequential workflow [OK]

Common Mistakes:

• Adding 'waitFor' incorrectly on all steps
• Omitting 'waitFor' causing deploy to run too early
• Misplacing 'waitFor' inside wrong steps