Triggering notifications
The notify
attribute allows you to trigger build notifications to different services. You can also choose to conditionally send notifications based on pipeline events like build state.
Add notifications to your pipeline with the notify
attribute. This sits at the same level as steps
in your pipeline YAML.
For example, to send a notification email every time a build is created:
Available notification types:
- Email: Send an email to the specified email address.
- Basecamp: Post a message to a Basecamp Campfire. Requires a Basecamp Chatbot to be configured in your Basecamp organization.
- Slack: Post a message to the specified Slack Channel. Requires a Slack Workspace or individual Slack notification services to be enabled for each channel.
- Webhooks: Send a notification to the specified webhook URL.
- PagerDuty
These types of notifications are available at the following levels.
Build | Step |
---|---|
Slack | Slack |
Basecamp | |
Webhook | |
PagerDuty |
Conditional notifications
To only trigger notifications under certain conditions, add the if
attribute.
For example, the following email notification will only be triggered if the build passes:
See Supported variables for more conditional variables that can be used in the if
attribute.
To trigger conditional notifications to a Slack channel, you will first need to configure Conditional notifications for Slack.
Add an email notification to your pipeline using the email
attribute of the notify
YAML block:
You can only send email notifications on entire pipeline events, specifically upon build.failing
and build.finished
.
Restrict notifications to finished builds by adding a conditional:
The email
attribute accepts a single email address as a string. To send notifications to more than one address, add each address as a separate email notification attribute:
Basecamp Campfire message
To send notifications to a Basecamp Campfire, you'll need to set up a chatbot in Basecamp as well as adding the notification to your pipeline.yml
file. Basecamp admin permission is required to setup your chatbot.
Campfire messages can only be sent using Basecamp 3.
- Add a chatbot to the Basecamp project or team that you'll be sending notifications to.
- Set up your chatbot with a name and an optional URL. If you'd like to include an image, you can find the Buildkite logo in our Brand assets.
- On the next page of the chatbot setup, copy the URL that Basecamp provides in the
curl
code snippet - Add a Basecamp notification to your pipeline using the
basecamp_campfire
attribute of thenotify
YAML block and the URL copied from your Basecamp chatbot:
The basecamp_campfire
attribute accepts a single URL as a string.
Basecamp notifications happen at the following events, unless you restrict them using conditionals:
build created
build started
build blocked
build finished
build skipped
Slack channel and direct messages
You can set notifications:
- On build status events in the Buildkite UI, by using your Slack Notification Service's 'Build State Filtering' settings.
- On step status and other non-build events, by extending the Slack Notification Service using the
notify
attribute in yourpipeline.yml
.
Before adding a notify
attribute to your pipeline.yml
, ensure an organization admin has set up either a Slack Workspace for a single authorization, or individual notification services for the channel or user that you want to post to. Buildkite customers on the Enterprise plan and using individual notification services can also check the 'Manage Notifications Services' checkbox to create, edit, or delete notification services. For detailed information about setting up a Workspace, see the Slack Workspace Integration page and Slack integration page for configuring individual notification services.
Once a Slack channel or workspace has been configured in your organization, add a Slack notification to your pipeline using the slack
attribute of the notify
YAML block.
When using an individual notification service, rather than a workspace, if you rename or modify the Slack channel for which the integration was set up, for example if you change it from public to private, you need to set up a new integration.🚧
When using only a channel name, you must specify it in quotes, as otherwise the #
will cause the channel name to be treated as a comment.
Notify a channel in all workspaces
You can notify a channel in all workspaces by providing the channel name in the pipeline.yml
.
Build-level notifications to the #general
channel of all configured workspaces:
Step-level notifications to the #general
channel of all configured workspaces:
Step-level vs build-level notifications
A step-level notify step will ignore the requirements of a build-level notification. If a build-level notification condition is that it runs only on main
, a step-level notification without branch conditionals will run on all branches.
Notify a user in all workspaces
You can notify a user in all workspaces by providing their username in the pipeline.yml
.
Build-level notifications to user @someuser
in all configured workspaces:
Step-level notifications to user @someuser
in all configured workspaces:
Notify a channel in one workspace
You can notify one particular workspace and channel or workspace and user by specifying the workspace name.
Build-level notifications:
Step-level notifications:
Notify multiple teams and channels
You can specify multiple teams and channels by listing them in the channels
attribute.
Build-level notifications:
Step-level notifications:
Notify only on first failure
You can filter build notifications to only trigger on the first failure using started_failing
.
Build-level notifications:
notify:
- slack: "#builds"
if: build.branch == "main" && pipeline.started_failing
Custom messages
You can define a custom message to send in the notification using the message
attribute.
Build-level notifications:
Step-level notifications:
Custom messages with user mentions
To mention a specific user in a custom message within a notification, use the <@user-id>
annotation, substituting userid
with the Slack user ID of the person to mention. See the Slack documentation on mentioning users for more details, including how to find a particular user's user ID. You can even mention user groups using the <!subteam^$subteam-id>
annotation (where the first subteam
is literal text)! See the Slack documentation on mentioning user groups for more information.
Build-level notifications:
Step-level notifications:
Build creator environment variable
You cannot substitute user
with the build creator environment variable value.
Conditional Slack notifications
You can also add conditionals to restrict the events on which notifications are sent:
See Supported variables for more conditional variables that can be used in the if
attribute.
Slack notifications happen at the following event:
build finished
An example to deliver slack notification when a step is soft-failed:
Webhooks
Send a notification to a webhook URL from your pipeline using the webhook
attribute of the notify
YAML block:
The webhook
attribute accepts a single webhook URL as a string. To send notifications to more than one endpoint, add each URL as a separate webhook attribute:
Webhook notifications happen at the following events, unless you restrict them using conditionals:
build created
build started
build blocked
build finished
PagerDuty change events
If you've set up a PagerDuty integration you can send change events from your pipeline using the pagerduty_change_event
attribute of the notify
YAML block:
Email notifications happen at the following event:
build finished
Restrict notifications to passed builds by adding a conditional:
Build states
A build state can be one of of the following values:
creating
, scheduled
, running
, passed
, failing
, failed
, blocked
, canceling
, canceled
, skipped
, not_run
.
You can query for finished
builds to return builds in any of the following states: passed
, failed
, blocked
, or canceled
.
When a triggered build fails, the step that triggered it will be stuck in the running
state forever.
When all the steps in a build are skipped (either by using skip attribute or by using if
condition), the build state will be marked as not_run
.
Unlike the notify
attribute, the build state value for a steps
attribute may differ depending on the state of a pipeline. For example, when a build is blocked within a steps
section, the state
value in the API response for getting a build retains its last value (for example, passed
), rather than having the value blocked
, and instead, the response also returns a blocked
field with a value of true
.
See the full build states diagram for more information on how builds transition between states.
Job states
A job state can be one of the following values:
pending
, waiting
, waiting_failed
, blocked
, blocked_failed
, unblocked
, unblocked_failed
, limiting
, limited
, scheduled
, assigned
, accepted
, running
, finished
, canceling
, canceled
, expired
, timing_out
, timed_out
, skipped
, or broken
.
See the full job states diagram for more information on how jobs transition between states.