fluxcd
Feature Request - Allow sending Slack Notifications in Threads
When performing a lot of deployments, a Slack channel can soon become overwhelmed with messages regarding upgrades. As an engineer, it can be easy to miss potentially important and useful information. It would be a lot more beneficial to group messages together that are part of the same action or event stream.
Slack supports the ability to send messages as part of a thread, by using the ts value of the parent message sent.
The Notification Controller currently uses Slack Incoming webhooks to post messages, which isn't suitable for this use-case so a new provider type would need to be introduced along with the existing Slack provider.
We had a talk about this at Flux Bug Scrub today
I can imagine several interesting ways this could be implemented that would be nice. We tried to think of ways that threads could be used without obscuring important information or making Flux behave statefully. We thought that each thread would need some sort of ID, and maybe that should be configurable, but the most natural ID for a thread is a commit hash. We thought that Flux needs to store information about the threads somewhere, and that could be in the remote service – it would make things more complicated, as Flux would need to check for an existing thread before it posts a new one, it would have some lookback period to avoid scanning long tranches of messages, maybe it would only use an existing thread if one can be found in the last 5 (configurable) messages, or if the cache has a thread with a matching commit hash for ID.
So when a new commit hash is taken in, a new thread would be opened, and the top-level message would behave like Git commit status: if the commit status remains green, then new messages are posted to the thread whenever they come in related to that commit. If a red message comes through, the top-level commit status can change to red, and the bot that posts the message can also check "post message directly to channel" – this way you would get to see any errors when they come, and they would generate notifications like you'd expect, but the general noise level in the notification channel would be limited by crossing the number of changes against the amount of volatility with respect to things succeeding.
It would be good to get these ideas together in an RFC document if you're interested in implementing such a thing.
I think that there are new Slack competitors coming out all the time, just yesterday there was an HN thread about a new open-source slack competitor that has a thread-centric approach. So I think this thread-centric ideal is one worth pursuing.
It is unlikely these types of changes get much attention from Flux maintainers before GA, but please don't let that deter you.
I'm willing to look into this, I have not created a RFC document before, but am willing to put in the effort to get some traction on this feature. Is this still open for discussion if so should I create a PR with the RFC document in this repo?
