mirror of
https://github.com/letic/terraform-provider-google.git
synced 2024-09-07 01:26:43 +00:00
150 lines
5.6 KiB
Markdown
150 lines
5.6 KiB
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:
|
||
|
||
* `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`.
|
||
|
||
* `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.
|
||
|
||
* `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.
|
||
|
||
---
|
||
|
||
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.
|