google-native.cloudbuild/v1.Trigger

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Required. ID of the project for which to configure automatic builds.

Configuration for manual approval to start a build invocation of this BuildTrigger.

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.

BitbucketServerTriggerConfig describes the configuration of a trigger that creates a build whenever a Bitbucket Server event is received.

Contents of the build template.

Human-readable description of this trigger.

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

EventType allows the user to explicitly set the type of event to which this BuildTrigger should respond. This field will be validated against the rest of the configuration if it is set.

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

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.

GitLabEnterpriseEventsConfig describes the configuration of a trigger that creates a build whenever a GitLab Enterprise event is received.

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 set to INCLUDE_BUILD_LOGS_WITH_STATUS, log url will be shown on GitHub page when build status is final. Setting this field to INCLUDE_BUILD_LOGS_WITH_STATUS for non GitHub triggers results in INVALID_ARGUMENT error.

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}

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.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Time when the trigger was created.

The provider-assigned unique ID for this managed resource.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

Whether or not approval is needed. If this is set on a build, it will become pending when created, and will need to be explicitly approved to start.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

The time when the approval decision was made.

Email of the user that called the ApproveBuild API to approve or reject a build at the time that the API was called.

Optional. An optional comment for this manual approval result.

The decision of this manual approval.

Optional. An optional URL tied to this manual approval result. This field is essentially the same as comment, except that it will be rendered by the UI differently. An example use case is a link to an external job that approved this Build.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

Cloud Storage bucket and optional object path, in the form "gs://bucket/path/to/somewhere/". (see Bucket Name Requirements). Files in the workspace matching any path pattern will be uploaded to Cloud Storage with this location as a prefix.

Path globs used to match files in the build's workspace.

Stores timing information for pushing all artifact objects.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

A list of images to be pushed upon the successful completion of all build steps. The images will be 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 is marked FAILURE.

A list of Maven artifacts to be uploaded to Artifact Registry upon successful completion of all build steps. Artifacts in the workspace matching specified paths globs will be uploaded to the specified Artifact Registry repository using the builder service account's credentials. If any artifacts fail to be pushed, the build is marked FAILURE.

A list of objects to be uploaded to Cloud Storage upon successful completion of all build steps. Files in the workspace matching specified paths globs will be uploaded to the specified Cloud Storage location using the builder service account's credentials. The location and generation of the uploaded objects will be stored in the Build resource's results field. If any objects fail to be pushed, the build is marked FAILURE.

A list of Python packages to be uploaded to Artifact Registry upon successful completion of all build steps. The build service account credentials will be used to perform the upload. If any objects fail to be pushed, the build is marked FAILURE.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Immutable. API Key that will be attached to webhook. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

Connected Bitbucket Server repositories for this config.

Time when the config was created.

Immutable. The URI of the Bitbucket Server host. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the config.

Optional. The network to be used when reaching out to the Bitbucket Server instance. The VPC network must be enabled for private service connection. This should be set if the Bitbucket Server instance is hosted on-premises and not reachable by public internet. If this field is left empty, no network peering will occur and calls to the Bitbucket Server instance will be made over the public internet. Must be in the format projects/{project}/global/networks/{network}, where {project} is a project number or id and {network} is the name of a VPC network in the project.

Secret Manager secrets needed by the config.

Optional. SSL certificate to use for requests to Bitbucket Server. The format should be PEM format but the extension can be one of .pem, .cer, or .crt.

Username of the account Cloud Build will use on Bitbucket Server.

UUID included in webhook requests. The UUID is used to look up the corresponding config.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

Identifier for the project storing the repository.

Identifier for the repository.

The ID of the webhook that was created for receiving events from this repo. We only create and manage a single webhook for each repo.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The resource name for the admin access token's secret version.

The resource name for the read access token's secret version.

Immutable. The resource name for the webhook secret's secret version. Once this field has been set, it cannot be changed. If you need to change it, please create another BitbucketServerConfig.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The BitbucketServerConfig specified in the bitbucket_server_config_resource field.

The Bitbucket server config resource that this trigger config maps to.

Key of the project that the repo is in. For example: The key for https://mybitbucket.server/projects/TEST/repos/test-repo is "TEST".

Filter to match changes in pull requests.

Filter to match changes in refs like branches, tags.

Slug of the repository. A repository slug is a URL-friendly version of a repository name, automatically generated by Bitbucket for use in the URL. For example, if the repository name is 'test repo', in the URL it would become 'test-repo' as in https://mybitbucket.server/projects/TEST/repos/test-repo.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

The operations to be performed on the workspace.

Artifacts produced by the build that should be uploaded upon successful completion of all build steps.

Secrets and secret environment variables.

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.

Google Cloud Storage bucket where logs should be written (see Bucket Name Requirements). Logs file names will be of the format ${logs_bucket}/log-${build_id}.txt.

Special options for this build.

TTL in queue for this build. If provided and the build is enqueued longer than this value, the build will expire and the build status will be EXPIRED. The TTL starts ticking from create_time.

Secrets to decrypt using Cloud Key Management Service. Note: Secret Manager is the recommended technique for managing sensitive data with Cloud Build. Use available_secrets to configure builds to access secrets from Secret Manager. For instructions, see: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets

IAM service account whose credentials will be used at build runtime. Must be of the format projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. ACCOUNT can be email address or uniqueId of the service account.

The location of the source files to build.

Substitutions data for Build resource.

Tags for annotation of a Build. These are not docker tags.

Amount of time that this build should be allowed to run, to second granularity. If this amount of time elapses, work on the build will cease and the build status will be TIMEOUT. timeout starts ticking from startTime. Default time is 60 minutes.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Configuration for manual approval of this build.

Result of manual approval for this Build.

The state of this build's approval.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.

Option to specify behavior when there is an error in the substitution checks. NOTE: this is always set to ALLOW_LOOSE for triggered builds and cannot be overridden in the build configuration file.

Global list of volumes to mount for ALL build steps Each volume is created as an empty volume prior to starting the build process. Upon completion of the build, volumes and their contents are discarded. Global volume names and paths cannot conflict with the volumes defined a build step. Using a global volume in a build with only one step is not valid as it is indicative of a build request with an incorrect configuration.

This field deprecated; please use pool.name instead.

Optional. Option to specify how default logs buckets are setup.

Requested disk size for the VM that runs the build. Note that this is NOT "disk free"; some of the space will be used by the operating system and build utilities. Also note that this is the minimum disk size that will be allocated for the build -- the build may run with a larger disk than requested. At present, the maximum disk size is 2000GB; builds that request more than the maximum are rejected with an error.

Option to specify whether or not to apply bash style string operations to the substitutions. NOTE: this is always enabled for triggered builds and cannot be overridden in the build configuration file.

A list of global environment variable definitions that will exist for all build steps in this build. If a variable is defined in both globally and in a build step, the variable will use the build step value. The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

Option to define build log streaming behavior to Google Cloud Storage.

Option to specify the logging mode, which determines if and where build logs are stored.

Compute Engine machine type on which to run the build.

Optional. Specification for execution on a WorkerPool. See running builds in a private pool for more information.

Requested verifiability options.

A list of global environment variables, which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's Secret. These variables will be available to all build steps in this build.

Requested hash for SourceProvenance.