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

---
# ----------------------------------------------------------------------------
#
#     ***     AUTO GENERATED CODE    ***    AUTO GENERATED CODE     ***
#
# ----------------------------------------------------------------------------
#
#     This file is automatically generated by Magic Modules and manual
#     changes will be clobbered when the file is regenerated.
#
#     Please read more about how to change this file in
#     .github/CONTRIBUTING.md.
#
# ----------------------------------------------------------------------------
layout: "google"
page_title: "Google: google_cloudbuild_trigger"
sidebar_current: "docs-google-cloudbuild-trigger"
description: |-
  Configuration for an automated build in response to source repository changes.
---

# google\_cloudbuild\_trigger

Configuration for an automated build in response to source repository changes.


To get more information about Trigger, see:

* [API documentation](https://cloud.google.com/cloud-build/docs/api/reference/rest/)
* How-to Guides
    * [Automating builds using build triggers](https://cloud.google.com/cloud-build/docs/running-builds/automate-builds)

<div class = "oics-button" style="float: right; margin: 0 0 -15px">
  <a href="https://console.cloud.google.com/cloudshell/open?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fdocs-examples.git&cloudshell_working_dir=cloudbuild_trigger_filename&cloudshell_image=gcr.io%2Fgraphite-cloud-shell-images%2Fterraform%3Alatest&open_in_editor=main.tf&cloudshell_print=.%2Fmotd&cloudshell_tutorial=.%2Ftutorial.md" target="_blank">
    <img alt="Open in Cloud Shell" src="//gstatic.com/cloudssh/images/open-btn.svg" style="max-height: 44px; margin: 32px auto; max-width: 100%;">
  </a>
</div>
## Example Usage - Cloudbuild Trigger Filename


```hcl
resource "google_cloudbuild_trigger" "filename-trigger" {
  trigger_template {
    branch_name = "master"
    repo_name   = "my-repo"
  }

  substitutions = {
    _FOO = "bar"
    _BAZ = "qux"
  }

  filename = "cloudbuild.yaml"
}
```

## Argument Reference

The following arguments are supported:



- - -


* `description` -
  (Optional)
  Human-readable description of the trigger.

* `disabled` -
  (Optional)
  Whether the trigger is disabled or not. If true, the trigger will never result in a build.

* `substitutions` -
  (Optional)
  Substitutions data for Build resource.

* `filename` -
  (Optional)
  Path, from the source root, to a file whose contents is used for the template. Either a filename or build template must be provided.

* `ignored_files` -
  (Optional)
  ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match
  extended with support for `**`.
  If ignoredFiles and changed files are both empty, then they are not
  used to determine whether or not to trigger a build.
  If ignoredFiles 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 ignoredFiles globs, then we do not trigger a build.

* `included_files` -
  (Optional)
  ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match
  extended with support for `**`.
  If any of the files altered in the commit pass the ignoredFiles filter
  and includedFiles 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 ignoredFiles filter
  and includedFiles is not empty, then we make sure that at least one of
  those files matches a includedFiles glob. If not, then we do not trigger
  a build.

* `trigger_template` -
  (Optional)
  Template describing the types of source changes to trigger a build.
  Branch and tag names in trigger templates are interpreted as regular
  expressions. Any branch or tag change that matches that regular
  expression will trigger a build.  Structure is documented below.

* `build` -
  (Optional)
  Contents of the build template. Either a filename or build template must be provided.  Structure is documented below.
* `project` - (Optional) The ID of the project in which the resource belongs.
    If it is not provided, the provider project is used.


The `trigger_template` block supports:

* `project_id` -
  (Optional)
  ID of the project that owns the Cloud Source Repository. If
  omitted, the project ID requesting the build is assumed.

* `repo_name` -
  (Optional)
  Name of the Cloud Source Repository. If omitted, the name "default" is assumed.

* `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.

* `branch_name` -
  (Optional)
  Name of the branch to build. Exactly one a of branch name, tag, or commit SHA must be provided.

* `tag_name` -
  (Optional)
  Name of the tag to build. Exactly one of a branch name, tag, or commit SHA must be provided.

* `commit_sha` -
  (Optional)
  Explicit commit SHA to build. Exactly one of a branch name, tag, or commit SHA must be provided.

The `build` block supports:

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

* `images` -
  (Optional)
  A list of images to be pushed upon the successful completion of all build steps.
  The images are pushed using the builder service account's credentials.
  The digests of the pushed images will be stored in the Build resource's results field.
  If any of the images fail to be pushed, the build status is marked FAILURE.

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


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.

## Attributes Reference

In addition to the arguments listed above, the following computed attributes are exported:


* `trigger_id` -
  The unique identifier for the trigger.

* `create_time` -
  Time when the trigger was created.


## Timeouts

This resource provides the following
[Timeouts](/docs/configuration/resources.html#timeouts) configuration options:

- `create` - Default is 4 minutes.
- `update` - Default is 4 minutes.
- `delete` - Default is 4 minutes.

## Import

Trigger can be imported using any of these accepted formats:

```
$ terraform import google_cloudbuild_trigger.default projects/{{project}}/triggers/{{trigger_id}}
$ terraform import google_cloudbuild_trigger.default {{project}}/{{trigger_id}}
$ terraform import google_cloudbuild_trigger.default {{trigger_id}}
```

-> If you're importing a resource with beta features, make sure to include `-provider=google-beta`
as an argument so that Terraform uses the correct provider to import your resource.