Identify the deployer job that sends the initial notification
On #1372 (closed), we're wrapping the deployment notifications in a single Slack thread. Logic is roughly the following:
- There's an active incident or a problem with the health status, and a deployment to prod starts.
- As the deployment progresses, deployer pipeline continuously notifies release-tools about the progress.
- release-tools consumes this information and
- Verifies if this is the first notification it receives and if it's, it posts a message to Slack.
- If it's not the initial notification, the message is sent as a thread.
Problem
We don't have a reliable way to identify when the first notification is sent to release-tools
, currently we're using gprd-migrations 50%
, but this might be unreliable because a deployer pipeline sent the notification at gprd migrations 100%
(see this pipeline, gprd-migration
job, and the initial notification sent to release-tools as examples).
We could also modify the code to use gprd-migrations
instead of gprd-migrations 50%
, but that will cause at least one additional message to be posted in the Slack channel.
Let's use this issue to figure out what'd be the best way to identify the initial notification.
Solution
gprd-migrations 50%
should be, in fact, the initial deployer job. The problem was around an unnecessary check on the deployer side mangling the triggers towards release-tools