Support Slack message updates and replies by ts

[amacrobert-meq]

It would be useful for the Slack integration to directly support

• the thread_ts option when posting a message, and
• the ts argument for updating a message.

This would allow notifications to reply to specific threads and update specific messages.

For example, supplying slack.thread_ts would respond to the Slack message by including it in the payload of chat.postMessage:

  template.app-sync-status: |
    message: |
      This is a reply to a thread
    slack:
      threadTs: "12345678.1234567"

And supplying slack.update_ts would update a Slack message by instigating a chat.update request and including its value in the ts option:

  template.app-sync-status: |
    message: |
      This is an updated message
    slack:
      updateTs: "12345678.1234567"

threadTs and updateTs would both be optional, and mutually exclusive.
threadTs and the existing groupingKey would be mutually exclusive.

Non-BC-breaking.

I am not familiar with Go so I probably won't be able to implement this myself, but I'm hoping this enhancement gets support from contributors.

[amacrobert-meq]

Example use case

To help illustrate how this would be useful, my specific use case is as follows:

1. A deployment is started in GitHub Actions, either manually or via a CD pipeline. An environment and branch are selected as part of the job.
2. This GitHub Actions job posts a new Slack message indicating that the deployment process has started.
3. The job builds the image from the specified branch if it doesn't exist, updates the k8s manifest to use the new image, and replies to the thread it started notifying that the image build is complete. Also included in the k8s manifest are the Slack channel ID and thread ID for the thread is started.
4. If at any point there was a failure during the GHA job, it will
   1. Update the top-level thread indicating failure
   2. Respond to the thread with details
5. ArgoCD picks up the change to the manifest, and notifies the channel ID left in step 3 that the deployment is starting. If this feature were implemented, it could reply to the original thread from the GHA job instead, keeping all deployment lifecycle updates contained to one thread. It could also update the top-level message, indicating successful deployment.

[kzap]

The threading option assumes you already know the threadId in advance

Another option we did in our own custom notifications webhook as to have a string in the top level message to use as a search string for the threadId

We would then search the channel or DM for a message with that string and if found post messages to that thread.

We also had the option for some messages to post to channel as part of the thread