Cloud Build uses build triggers to enable CI/CD automation. You can configure triggers to listen for incoming events, such as when a new commit is pushed to a repository or when a pull request is initiated, and then automatically execute a build when new events come in. You can also configure triggers to build code on any changes to your source repository or only on changes that match certain criteria.
This page provides an overview of each trigger type and capabilities associated with triggers.
Repository event triggers
Cloud Build lets you to automatically execute builds on repository events such as pushes or pull requests. You can connect external repositories, such as repositories in GitHub or Bitbucket, to Cloud Build or use code in Cloud Source Repositories for your builds. While you can connect any source repository to Cloud Build, Cloud Build provides specific repository event triggers you can can use to integrate specific source code management systems (SCMs). This section discusses available repository event triggers.
GitHub triggers
You can create GitHub triggers to automatically execute builds in response to repository events, such as pushes or pull requests. You can view the trigger's build status on GitHub and Google Cloud console. You can also use the Cloud Build GitHub app to connect and build code in GitHub. To learn more, see Building repositories from GitHub.
GitHub Enterprise triggers
You can create triggers for repositories hosted on a GitHub Enterprise instance, including instances hosted in an on-premises environment and not reachable over a public internet connection. GitHub Enterprise triggers can be used to execute builds in response to pushes or pull requests from a GitHub Enterprise instance. To learn more, see Building repositories from GitHub Enterprise.
GitLab Enterprise Edition triggers
You can create triggers for repositories hosted on a GitLab Enterprise Edition instance, including instances hosted in a private network. GitLab Enterprise Edition triggers can be used to execute builds in response to commit pushes or pull requests associated with your GitLab Enterprise Edition repository. To learn more, see Building repositories from GitLab Enterprise Edition.
Bitbucket Server triggers
You can create triggers for repositories hosted on a Bitbucket Server instance, including instances hosted in an on-premises environment. You can connect your Bitbucket Server repository to Cloud Build multiple times with multiple host connections. To learn more on how to create triggers to execute builds in response to events, see Building repositories from Bitbucket Server.
Bitbucket Data Center triggers
You can create triggers for repositories hosted on a Bitbucket Data Center instance, including instances hosted in an on-premises environment. Bitbucket Data Center triggers can be used to execute builds in response to events such as commit pushes or pull requests. To learn more, see Building repositories from Bitbucket Data Center.
Bitbucket Cloud triggers
You can create triggers for repositories hosted in Bitbucket Cloud. Bitbucket Cloud triggers can be used to execute builds in response to events such as commit pushes or pull requests. To learn more, see Building repositories from Bitbucket Cloud.
Manual triggers
You can create manual triggers to execute builds manually and override defined substitution variable values at invocation time prior to executing a build. You can also configure manual triggers to run on a schedule. To learn more, see Manually build code in source repositories.
Pub/Sub triggers
You can create Pub/Sub triggers to execute builds in response to
any message published over Pub/Sub. For example, you can use
Pub/Sub triggers for building in response to image pushes to
Artifact Registry. In this case, you can configure your trigger to use filters to
execute a build only if the pushed image matches a specific tag, such as prod
.
Additionally, Pub/Sub triggers can be configured to subscribe to
any Pub/Sub topic. To learn more, see
Automate builds in response to Pub/Sub events.
Webhook triggers
You can create webhook triggers to execute builds in response to webhooks. Webhook events sent to a custom URL enable you to directly connect external systems and external source code management systems (SCMs), such as Bitbucket.com, Bitbucket Server, or GitLab, to Cloud Build. When creating webhook triggers, you can also define your build configuration inline on your trigger to control which repositories your trigger clones during build time rather than explicitly specifying a source. To learn more, see Automate builds in response to webhook events. Additionally, to learn to use webhook triggers to build repositories from specific SCMs, see Building repositories from Bitbucket Server, Building repositories from Bitbucket Cloud, and Building repositories from GitLab.
Trigger capabilities
Cloud Build triggers provide capabilities that give you fine-grained control over how a build is executed. This section discusses various capabilities associated with triggers.
Scheduled manual triggers
You can schedule manual triggers to automatically execute builds on a predefined schedule. For example, you may want to configure a scheduled trigger to run a build every Saturday at 6:00 AM. To schedule builds, you can create a manual trigger and invoke the trigger using Cloud Scheduler. To learn more, see Schedule builds.
Filtering events
Cloud Build uses
Common Expression Language (CEL) with the
variable, build
, on fields listed in the
Build resource to access
fields associated with your build event such as your trigger ID, image list, or
substitution values. You can use the filter
string to filter build events in
your build config file using any field listed in the
Build resource. To learn
more, see Use CEL to filter build events
Substitution variables
You can specify substitution variables in your build configuration file to substitute specific values at build time. For example, you may want to use substitution variables if a value is not known until build time or if you want to re-use an existing build request with different variables. Cloud Build provides default substitutions you can use for builds invoked by triggers, such as variables mapping to your trigger name or repository name. You can also define your own substitution variables. To learn more, see Substituting variable values.
Bash parameter expansions
You can apply bash parameter expansions to substitution variable values. Bash parameter expansions allow you to manipulate strings associated with existing variables. For example, you can use bash parameter expansions to capitalize letters or replace a substring. To learn more, see Bash parameter expansions.
Payload bindings
You can store part of your trigger's event payload as a substitution variable by using payload bindings. Variables associated with a payload are referred to as bindings and are available for builds invoked by both push and pull events. You can use bindings to access additional data related to your build, such as the author of a pull request. To learn more, see Payload bindings.
Approvals
You can configure triggers to not immediately execute a build, but instead mark a build as pending until approved. If a user with permissions approves a pending build, the build starts. If the approval is denied, the build doesn't start. To learn how to configure triggers that require approval, see Gate builds on approval.
Build status notifications
You can configure Cloud Build notifiers to listen to build event
updates from on the Pub/Sub cloud-builds
topic. Notifiers can
also filter messages received by the topic and send messages to your connected
services. Cloud Build provides and maintains deployable notifier
images in the
cloud-build-notifiers
repository.
You can configure notifications using a Cloud Build notifier,
such as BigQuery,
HTTP,
Slack, or
SMTP or
create your own notifier.
What's next
- Learn how to create and manage build triggers.