This topic describes how to automate builds using Container Builder and Cloud Source Repositories.
You can configure Container Builder to automatically build a new image any time a user pushes a change to files stored in Cloud Source Repositories. Events that initiate automatic builds are called build triggers. These triggers can help ensure that your container images are kept up to date. You can also use them to build and test feature branches.
Before you begin
Enable the Container Builder API.
You need source code in Cloud Source Repositories
- You need either a
Dockerfileor a Container Builder build config file
In addition to these prerequisites, you may find the following information helpful:
Build triggers use shallow clones of a repository. With shallow clones, only the single commit that triggered the build is checked out in the workspace to build. For more information, and to learn how to include more of your repositories history, see Unshallowing clones.
If you use another hosted Git provider, such as on GitHub or Bitbucket, and you have not yet mirrored the repository into Cloud Source Repositories, you must have the
cloudbuilds.builds.createpermission for the Google Cloud Platform project with which you're working. This permission is typically granted through the
When you set up a build trigger with an external repository for the first time, you'll need to set up authorization with that repository. For more information, see Adding a Repository as a Remote.
After you've set up your external repository, Cloud Source Repositories creates a mirror of your repository.
For information on the quotas and limits for Container Builder, see Quotas & Limits in the Container Builder documentation.
Creating a build trigger
To create a new build trigger:
Open the Container Registry page in the Google Cloud Platform Console.
Select your project and click Open.
In the left nav, click Build triggers.
Click Create trigger.
Select Cloud Source Repository.
From the list of available repositories, select the desired repository, then click Continue.
Enter the following trigger settings:
- Trigger Name: An optional name for your trigger.
- Trigger Type: You can set a trigger to start a build on commits to a particular branch, or on commits that contain a particular tag. In either case, you can specify a regular expression with the branch or tag value to match.
- Build Configuration: The
Dockerfileor build config file (located in the remote repository) to use for each build that the trigger starts.
Using a Dockerfile
To use a Dockerfile for your build configuration, you'll need to specify the Dockerfile directory and supply a name for the resulting image.
When you've provided the Dockerfile and image name, you'll see a preview of the
docker build command that your build will execute and a summary of the trigger
configuration. Click Create trigger to save the build trigger.
Using a build config file
To use a build config file for your build configuration, you'll need to provide the location of a build config file.
Once you've set the location, you'll see a summary of the trigger. Click Create trigger to save the build trigger.
Testing a build trigger
To manually test a build trigger, click Run trigger on your trigger's entry in the triggers list.
Skipping a build trigger
In some cases, you may want to make a change to your source code but you don't want to trigger a build. For example, you might not want to trigger a build when you update documentation or configuration files.
In such scenarios, you can include
[skip ci] or
[ci skip] in the commit message, and a build will not be triggered.
Author: A User <email@example.com> Date: Tue Apr 3 12:03:35 2018 -0700 Fixed customer affecting issue. [skip ci]
If you want to run a build on that commit later, use the Run trigger button.
To build your source on a Git repo, Cloud Source Repositories performs a shallow clone of the repo. This means that only the single commit that triggered the build is checked out in the workspace to build. Cloud Source Repositories does not check out any other branches or history. This is done for efficiency, so that builds don't have to wait to fetch the whole repository and history just to build a single commit.
If you want to include more of your repo's history in the build, add a build step in your build config file to "unshallow" the clone. For example:
steps: - name: gcr.io/cloud-builders/git args: ['fetch', '--unshallow'] ...
- Learn how to start builds manually in Container Builder.