terraform-provider-google/website/docs/r/cloudbuild_trigger.html.markdown

---
layout: "google"
page_title: "Google: google_cloudbuild_trigger"
sidebar_current: "docs-google-cloudbuild-trigger"
description: |-
  Creates a new build trigger within GCR.
---

# google\_cloudbuild\_trigger

Creates a new build trigger within GCR. For more information, see
[the official documentation](https://cloud.google.com/container-builder/docs/running-builds/automate-builds)
and
[API](https://godoc.org/google.golang.org/api/cloudbuild/v1#BuildTrigger).

## Example Usage

```hcl
resource "google_cloudbuild_trigger" "build_trigger" {
  project  = "my-project"
  trigger_template {
    branch_name = "master"
    project     = "my-project"
    repo_name   = "some-repo"
  }
  build {
    images = ["gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA"]
    step {
      name = "gcr.io/cloud-builders/docker"
      args = "build -t gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA -f Dockerfile ."
    }
  }
}
```

OR

```hcl
resource "google_cloudbuild_trigger" "build_trigger" {
  project  = "my-project"
  trigger_template {
    branch_name = "master"
    project     = "my-project"
    repo_name   = "some-repo"
  }
  filename = "cloudbuild.yaml"
}
```


## Argument Reference

(Argument descriptions sourced from https://godoc.org/google.golang.org/api/cloudbuild/v1#BuildTrigger)

The following arguments are supported:

* `build` - (Optional) A build resource in the Container Builder API.
Structure is documented below. At a high
level, a `build` describes where to find source code, how to build it (for
example, the builder image to run on the source), and where to store
the built artifacts. Fields can include the following variables, which
will be expanded when the build is created:
  * `$PROJECT_ID`: the project ID of the build.
  * `$BUILD_ID`: the autogenerated ID of the build.
  * `$REPO_NAME`: the source repository name specified by RepoSource.
  * `$BRANCH_NAME`: the branch name specified by RepoSource.
  * `$TAG_NAME`: the tag name specified by RepoSource.
  * `$REVISION_ID` or `$COMMIT_SHA`: the commit SHA specified by RepoSource
    or resolved from the specified branch or tag.
  * `$SHORT_SHA`: first 7 characters of `$REVISION_ID` or `$COMMIT_SHA`.

* `description` - (Optional) A brief description of this resource.

* `ignored_files` - (Optional) `ignored_files` and `included_files` are file glob matches using http://godoc/pkg/path/filepath#Match extended with support for "\*\*". If `ignored_files` and changed files are both empty, then they are not used to determine whether or not to trigger a build. If `ignored_files` is not empty, then we ignore any files that match any of the ignored_file globs. If the change has no files that are outside of the `ignored_files` globs, then
    we do not trigger a build.

* `included_files` - (Optional) If any of the files altered in the commit pass the `ignored_files` filter and `included_files` is empty, then as far as this filter is concerned, we should trigger the build. If any of the files altered in the commit pass the `ignored_files` filter and `included_files` is not empty, then we make sure that at least one of those files matches a `included_files` glob. If not, then we do not trigger a build.

* `filename` - (Optional) Specify the path to a Cloud Build configuration file
in the Git repo. This is mutually exclusive with `build`. This is typically
`cloudbuild.yaml` however it can be specified by the user.

*  `project` - (Optional) The ID of the project that the trigger will be created in.
Defaults to the provider project configuration.

* `substitutions`: (Optional) User-defined substitutions.
User-defined substitutions must conform to the following rules:
  *  Substitutions must begin with an underscore (`_`) and use only
     uppercase-letters and numbers (respecting the regular expression
     `_[A-Z0-9_]+`). This prevents conflicts with built-in substitutions.
  *  Unmatched keys in the template will cause an error (for example, if a build
     request includes `$_FOO` and the substitutions map doesn’t define `_FOO`).
  *  Unmatched keys in the parameters list will result in an error (for example,
     if a substitutions map defines `_FOO` but the build request doesn't include `$_FOO`).
  *  To include a literal `$_VARIABLE` in the template, you must escape with `$$`.
  *  You can explicitly denote variable expansion using the `${_VAR}` syntax. This prevents
     ambiguity in cases like `${_FOO}BAR`, where `$_FOO` is a variable.
  *  The number of parameters is limited to 100 parameters.
  *  The length of a parameter key and the length of a parameter value
     are limited to 100 characters.

* `trigger_template` - (Optional) Location of the source in a Google
Cloud Source Repository. Structure is documented below.

---

The `build` block supports:

* `images` - (Optional) A list of images to be pushed upon the successful
completion of all build steps.

* `step` - (Optional) The operations to be performed on the workspace.
Structure is documented below.

* `tags` - (Optional) Tags for annotation of a build. **These are not docker tags**

---

The `step` block supports:

* `name` - (Optional) The name of the container image that will run this
particular build step. If the image is available in the host's Docker
daemon's cache, it will be run directly. If not, the host will attempt to
pull the image first, using the builder service account's credentials if
necessary. The Docker daemon's cache will already have the latest versions
of all of the officially supported build steps
(https://github.com/GoogleCloudPlatform/cloud-builders).
The Docker daemon will also have cached many of the layers for some popular
images, like "ubuntu", "debian", but they will be refreshed at the time you
attempt to use them. If you built an image in a previous build step, it will
be stored in the host's Docker daemon's cache and is available to use as
the name for a later build step.

* `args` - (Optional) A list of arguments that will be presented to the step
when it is started. If the image used to run the step's container has an
entrypoint, the `args` are used as arguments to that entrypoint. If the image
does not define an entrypoint, the first element in args is used as the
entrypoint, and the remainder will be used as arguments.

---

The `trigger_template` block supports:

* `branch_name` - (Optional) Name of the branch to build.

* `commit_sha` - (Optional) Explicit commit SHA to build.

* `dir` - (Optional) Directory, relative to the source root, in which to run
the build. This must be a relative path. If a step's `dir` is specified and
is an absolute path, this value is ignored for that step's execution.

* `project` - (Optional) ID of the project that owns the Cloud Source Repository.

* `repo_name` - (Optional) Name of the Cloud Source Repository.

* `tag_name` - (Optional) Name of the tag to build.