2018-05-07 19:53:34 +00:00
|
|
|
|
---
|
|
|
|
|
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 ."
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2018-06-05 17:17:20 +00:00
|
|
|
|
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"
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
2018-05-07 19:53:34 +00:00
|
|
|
|
## Argument Reference
|
|
|
|
|
|
|
|
|
|
(Argument descriptions sourced from https://godoc.org/google.golang.org/api/cloudbuild/v1#BuildTrigger)
|
|
|
|
|
|
|
|
|
|
The following arguments are supported:
|
|
|
|
|
|
|
|
|
|
* `description` - (Optional) A brief description of this resource.
|
|
|
|
|
|
|
|
|
|
* `trigger_template` - (Optional) Location of the source in a Google
|
|
|
|
|
Cloud Source Repository. Structure is documented below.
|
|
|
|
|
|
|
|
|
|
* `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`.
|
|
|
|
|
|
2018-06-05 17:17:20 +00:00
|
|
|
|
* `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.
|
|
|
|
|
|
2018-07-25 20:38:35 +00:00
|
|
|
|
* `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.
|
|
|
|
|
|
2018-05-07 19:53:34 +00:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
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.
|