Cloud Build v1 API - Class BuildTrigger (2.6.0)

Reference documentation and code samples for the Cloud Build v1 API class BuildTrigger.

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

Autodetect build configuration. The following precedence is used (case insensitive):

1. cloudbuild.yaml
2. cloudbuild.yml
3. cloudbuild.json
4. Dockerfile

Currently only available for GitHub App Triggers.

Contents of the build template.

BuildTriggerName-typed view over the Name resource name property.

Output only. Time when the trigger was created.

Human-readable description of this trigger.

If true, the trigger will never automatically execute a build.

Path, from the source root, to the build configuration file (i.e. cloudbuild.yaml).

Optional. A Common Expression Language string.

The file source describing the local or remote Build template.

GitHubEventsConfig describes the configuration of a trigger that creates a build whenever a GitHub event is received.

Mutually exclusive with trigger_template.

Gets whether the "autodetect" field is set

Gets whether the "filename" field is set

Output only. Unique identifier of the trigger.

ignored_files and included_files are file glob matches using https://golang.org/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.

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.

User-assigned name of the trigger. Must be unique within the project. Trigger names must meet the following requirements:

• They must contain only alphanumeric characters and dashes.
• They can be 1-64 characters long.
• They must begin and end with an alphanumeric character.

PubsubConfig describes the configuration of a trigger that creates a build whenever a Pub/Sub message is published.

The configuration of a trigger that creates a build whenever an event from Repo API is received.

The Trigger name with format: projects/{project}/locations/{location}/triggers/{trigger}, where {trigger} is a unique identifier generated by the service.

The service account used for all user-controlled operations including UpdateBuildTrigger, RunBuildTrigger, CreateBuild, and CancelBuild. If no service account is set, then the standard Cloud Build service account ([PROJECT_NUM]@system.gserviceaccount.com) will be used instead. Format: projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT_ID_OR_EMAIL}

ServiceAccountName-typed view over the ServiceAccount resource name property.

The repo and ref of the repository from which to build. This field is used only for those triggers that do not respond to SCM events. Triggers that respond to such events build source at whatever commit caused the event. This field is currently only used by Webhook, Pub/Sub, Manual, and Cron triggers.

Substitutions for Build resource. The keys must match the following regular expression: ^_[A-Z0-9_]+$.

Tags for annotation of a BuildTrigger

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.

Mutually exclusive with github.

WebhookConfig describes the configuration of a trigger that creates a build whenever a webhook is sent to a trigger's webhook URL.