Creating and managing build triggers

A Cloud Build trigger automatically starts a build whenever you make any changes to your source code. You can configure the trigger to build your code on any changes to the source repository or only changes that match certain criteria.

This page explains how to connect to source repositories such as GitHub and Bitbucket, and create build triggers to build the code in the repositories.

Before you begin

  • You need source code in Cloud Source Repositories, GitHub, or Bitbucket.
  • You need either a Dockerfile or a Cloud Build config file.

Connecting to source repositories

You must first connect Cloud Build to your source repository before building the code in that repository. Your repositories in Cloud Source Repositories are connected to Cloud Build by default; you can directly create triggers for your repositories in Cloud Source Repositories without manually connecting to them. Use the following steps to connect to GitHub and Bitbucket:

  1. Open the Triggers page in the Google Cloud Console.

    Open the Build triggers page

  2. Select your project and click Open.

  3. Click Connect Repository.

  4. Select the repository where you've stored your source code.

    If you select GitHub (mirrored) or Bitbucket (mirrored) as your source repository, Cloud Build mirrors your repository in Cloud Source Repositories and uses the mirrored repository for all its operations.

  5. Click Continue.

  6. Authenticate to your source repository with your username and password.

  7. From the list of available repositories, select the desired repository, then click Connect repository.

    For external repositories, such as GitHub and Bitbucket, you must have owner-level permissions for the Google Cloud project with which you're working.

  8. Click Add trigger to continue creating a build trigger to automate builds for the source code in the repository, or click Done.

Creating a build trigger

CONSOLE

  1. Open the Triggers page in the Google Cloud Console.

    Open the Build triggers page

  2. Select your project and click Open.

  3. Click Create trigger.

  4. Enter the following trigger settings:

    • Repository: From the list of available repositories, select the desired repository.

    • Name: Enter a 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. For information on acceptable regular expression syntax, see RE2 syntax.

    • Included files (optional): Changes to these files will trigger a build. You can use glob strings to specify multiple files with wildcard characters. Acceptable wildcard characters include the characters supported by Go Match, **, and alternation.
    • Ignored files (optional): Changes to these files will not trigger a build. You can use glob strings to specify multiple files with wildcard characters. Acceptable wildcard characters include the characters supported by Go Match, **, and alternation.
    • If you push a change to your repository on an existing branch, Cloud Build looks at the files changed between the commit you just pushed and the commit to which the branch previously pointed.

    • If you push a change to a newly created branch or tag, then Cloud Build treats all the files in the repository as changed files.

    • If you delete a branch or a tag, Cloud Build does not trigger a build.

    • Build Configuration: The Dockerfile or build config file (located in the remote repository) to use for each build that the trigger starts.

    To use a Dockerfile for your build configuration, you'll need to specify the Dockerfile directory and supply a name for the resulting image. Optionally, you can also provide a timeout for your build.

    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.

    To use a build config file for your build configuration, you'll need to provide the location of your build config file.

    • Substitution variables (optional): If you selected the Cloud Build config file as your build config option, you can choose to define trigger-specific substitution variables using this field. For example, say you're creating multiple triggers where each trigger deploys your app to a specific environment. You can specify that your app is deployed to an environment in your build config file and then use this field to define substitution variables specifying which environment this trigger should deploy to. For information on specifying substitution values in build config files, see Substituting variable values.
  5. Click Create trigger to save the build trigger.

GCLOUD

To create a trigger if your source code is in Cloud Source Repositories:

    gcloud beta builds triggers create cloud-source-repositories \
    --repo=[REPO_NAME] \
    --branch-pattern=".*" \
    --build-config=[BUILD_CONFIG_FILE] \

Where:

  • --repo is the name of your repository.
  • --branch-pattern is your trigger type specified as a string. In the example above, we specify ".*", which indicates that a build will be triggered when changes are pushed to any branch in the repository. You can also use --tag-pattern to indicate that builds will only be triggered when pushed to specific tags.
  • --build-config is the path to your build configuration file.

For a complete list of flags, see the gcloud reference for how to create triggers for Cloud Source Repositories.

To create a trigger if your source code is in GitHub:

    gcloud beta builds triggers create github \
    --repo-name=[REPO_NAME] \
    --repo-owner=[REPO_OWNER] \
    --branch-pattern=".*" \
    --build-config=[BUILD_CONFIG_FILE] \

Where:

  • --repo-name is the name of your repository.
  • --repo-owner is the name of the repository's owner.
  • --branch-pattern is your trigger type specified as a string. In the example above, we specify ".*", which indicates that a build will be triggered when changes are pushed to any branch in the repository. You can also use --tag-pattern to indicate that builds will be only be triggered when pushed to specific tags or --pull-request-pattern to indicate the base git branch to match all pull request events.
  • --build-config is the path to your build configuration file.

For a complete list of flags, see the gcloud reference for how to create triggers for GitHub.

After you run the gcloud command to create a trigger using Cloud Source Repositories or GitHub, you should see an output similar to the following:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

Testing a build trigger

To manually test a build trigger:

  1. Open the Triggers page in the Google Cloud Console.

    Open the Build triggers page

  2. Locate your trigger in the list and then click Run trigger.

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.

If you want to run a build on that commit later, use the Run trigger button in the Triggers page.

Including the repository history in a build

To build your source on a Git repo, Cloud Build 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 Build 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']
...

For more information on git fetch see git reference. For instructions on writing a build config file see Build config overview.

If you're building using GitHub App triggers, Cloud Build fetches your source from a Cloud Storage archive. Therefore, you must first clone your Git repo before fetching it:

 steps:
 - name: gcr.io/cloud-builders/git
   args: ['clone', '[REPOSITORY_URL]']
 ...

Where [REPOSITORY_URL] is the URL of the repository to clone.

What's next

هل كانت هذه الصفحة مفيدة؟ يرجى تقييم أدائنا:

إرسال تعليقات حول...

Cloud Build Documentation