Notify Slack when the main branch build fails
#1390
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is largely based on similar work in other Weaveworks projects[1], but with a bit of extra information that will hopefully be useful to folks who want to investigate the failure. There are a few bits of this workflow that I don't love: the `jq` hackery to extract the first line of the commit message isn't particularly pleasant, but I couldn't see anything exposed by GitHub that gives us just the commit's subject line. Telling `jq` to JSON-encode the commit subject also feels like a bit of a hack, but these are the perils of telling GitHub how to write YAML that writes JSON that writes Slack's custom `mrkdwn` syntax. If we want to add any more context to these messages (for instance, which bits of the run failed and how long they took), I would strongly recommend taking the functionality here and re-implementing it in a scripting language of choice (Python seems like a good fit, but anything else that has JSON support in its standard library and comes bundled with Ubuntu would probably work just as well). I've tentatively left the job open to the prospect of adding other build failure notifications (Slack or otherwise). Normally, I'd think of this as a premature generalization, but it plays nicely into GitHub's way of evaluating whether to run a job at all. [1]: https://github.com/search?q=org%3Aweaveworks+action-slack-notifier&type=code
jpellizzari
approved these changes
Feb 3, 2022
| - acceptance-tests-2 | ||
| - acceptance-tests-3 | ||
| - ui-tests | ||
| if: ${{ failure() }} |
There was a problem hiding this comment.
👍 Didn't know we could do this. Branching in yaml, what a time to be alive.
rokshana-b
approved these changes
Feb 3, 2022
dhwthompson
force-pushed
the
team-build-notifications
branch
from
19aaba1
to
64ac67a
Compare
`github.sha` is available for more events than just a `push` event. Granted, we only want to send these notifications on `push` events, but it's better to have the job successfully do nothing in other cases, rather than fail.
For other event types (like `pull_request`), the head commit information isn't available in quite the same way, so rather than have the intermediate commit summary step fail, we can set a condition on its execution so that it doesn't even try. The `event_name` condition on the final step is probably redundant under the current setup (unless someone tries to set up a pull request *from* the `main` branch), but it's probably worth having as an extra guard in case we change the configuration for when this workflow runs.
jpellizzari
pushed a commit
that referenced
this pull request
Mar 3, 2022
This is largely based on similar work in other Weaveworks projects[1], but with a bit of extra information that will hopefully be useful to folks who want to investigate the failure. There are a few bits of this workflow that I don't love: the `jq` hackery to extract the first line of the commit message isn't particularly pleasant, but I couldn't see anything exposed by GitHub that gives us just the commit's subject line. Telling `jq` to JSON-encode the commit subject also feels like a bit of a hack, but these are the perils of telling GitHub how to write YAML that writes JSON that writes Slack's custom `mrkdwn` syntax. If we want to add any more context to these messages (for instance, which bits of the run failed and how long they took), I would strongly recommend taking the functionality here and re-implementing it in a scripting language of choice (Python seems like a good fit, but anything else that has JSON support in its standard library and comes bundled with Ubuntu would probably work just as well). I've tentatively left the job open to the prospect of adding other build failure notifications (Slack or otherwise). Normally, I'd think of this as a premature generalization, but it plays nicely into GitHub's way of evaluating whether to run a job at all. [1]: https://github.com/search?q=org%3Aweaveworks+action-slack-notifier&type=code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is largely based on similar work in other Weaveworks projects, but with a bit of extra information that will hopefully be useful to folks who want to investigate the failure.
There are a few bits of this workflow that I don't love: the
jqhackery to extract the first line of the commit message isn't particularly pleasant, but I couldn't see anything exposed by GitHub that gives us just the commit's subject line. Tellingjqto JSON-encode the commit subject also feels like a bit of a hack, but these are the perils of telling GitHub how to write YAML that writes JSON that writes Slack's custommrkdwnsyntax.If we want to add any more context to these messages (for instance, which bits of the run failed and how long they took), I would strongly recommend taking the functionality here and re-implementing it in a scripting language of choice (Python seems like a good fit, but anything else that has JSON support in its standard library and comes bundled with Ubuntu would probably work just as well).
I've tentatively left the job open to the prospect of adding other build failure notifications (Slack or otherwise). Normally, I'd think of this as a premature generalization, but it plays nicely into GitHub's way of evaluating whether to run a job at all.
Reviewer notes
This is one instance where a reviewer is going to get a better impression by looking at the individual commits:
mainbranch or spamming the team.I’m also open to feedback on the information we’re presenting in the notifications. Is there something missing that would be really useful? Is there something there that isn’t helpful? We’re a little limited in what GitHub makes available without checking out the source code or running more advanced scripting, but suggestions are always welcome.