I tend to have this setup as a Cloud Build trigger, setup with Manual Invocation, with an inline configuration:
steps:
- name: busybox
args:
- 'false'
Then, I can fire a failure at my convenience.
Once the trigger is fired, check the Logs for the Cloud Function. You then see the payload for a failure. It might look something like this (truncated for clarity):
{
"id": "unique_guid",
"status": "FAILURE",
"projectId": "MyProjectId",
"buildTriggerId": "dca9b62d-0d57-43a6-a8e3-9023ac129ee8",
"logUrl": "https://console.cloud.google.com/cloud-build/builds/unique_guid",
"substitutions": {
"SHORT_SHA": "f0fe4b6",
"TRIGGER_NAME": "mock-failure",
...
}
From here, you can see what sort of values you have to play with in your template.
Be sure to delete your Cloud Function once you’re finished with it!
The template format uses Go’s template functionality, where the values in your payload are accessible via {{.Build}}
.
For example, if you want the title of your notification to include the trigger name, falling back to the trigger ID, and then the build status:
{
"title": "Build
{{if .Build.Substitutions.TRIGGER_NAME}}
{{.Build.Substitutions.TRIGGER_NAME}}
{{else}}
{{.Build.BuildTriggerId}}
{{end}}: {{.Build.Status}}",
...
All these values were available in the payload information.
You can see more examples in the Cloud Build Notifiers GitHub repo, including examples for customising Slack (which uses blockkit, and GitHub (where you can customise using the Issue Create API, for example, adding default labels).
Learn more about: