GoogleChat: ThreadKey

[TJM]

It would be nice if we could (optionally) set a &threadKey=........ Initially this should be namespace/release_name. This could get really fancy, where you have some sort of "templating language" to allow people to customize how they appear, but for now we just want the "upgrading" and the "upgraded" message to appear in the same thread, and would really like it if they were all together.. see screenshot.

I am not sure which other "handlers" support a simple threadKey type argument on the webhook URL, but I would bet that Google did not innovate that :)

~tommy

[dtuite]

I agree this would be good. It should work for Slack too.

There is related discussion in #45. If you're not using --wait with Helm, then the second "upgraded" message is redundant, because Helm doesn't actually check that your upgrade happens successfully (and thus Kubewise doesn't have the information either). Even if your upgrade completely fails, you will get an instantaneous "upgraded" message in your chat from kubewise. For people who are not using --wait, it would be best to just omit this second message completely (removing the need for a thread).

[TJM]

I agree with the concepts of #45 and think that would make things "better" :)

Even without the (extraneous) "Upgraded" message, I was thinking we should do a thread per release. We have ~150 different charts, in each of 3 namespaces currently, and think it might be better to keep the namespace/releasename notifications each in their own thread, rather than each as a separate message.

[dtuite]

If #45 was done, and assuming you are not using --wait, I think this issue (#49) would be a no-op. If upgrading a chart is just a single message then there is nothing to go into the thread. Or am I missing something?

Perhaps the idea is that all upgrades of Chart A in the Production Namespace (for example) would go into a single thread?

[TJM]

Correct, my goal would be to combine all the upgrades of namespace/release-name into a single thread, instead of having to search back in the message history to find the last time someone changed something on this release.

Your mention of "Chart A" goes back to my initial thoughts of this may end up needing to be sortof "template" based where you could maybe use a "go-template" to define the threadkey with a set of "defined" variables?