Support Slack message updates and replies by ts

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.

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

[CreMindES]

Picking up the thread, I also second @amacrobert-meq's proposal. We would exactly have the same use case.

@kzap, yes, in the outlined use case, you need to know the thread ID, and it is exactly the case, since CI knows it in advance after it posts the first message. And of course, nothing would stop you from referencing that thread ID value in an annotation entry in the updateTs and threadTs template field, e.g. `threadTs: {{index .app.metadata.annotations "foo.com/slackTs"}}. The latter could be easily set by CI/CD pipeline after posting the parent message, but before calling the API's sync operation.

This would be a small-ish change, but would eliminate the need to re-implement the relevant parts of this repo in a custom CI/CD pipeline.

[willianpaixao]

@amacrobert-meq @CreMindES I've drafted a PR. #410

[oles-visible]

That's just fascinating! ChatGPT has already implemented this feature in its hallucinations and I was wondering why it doesn't work. Bummer! After the investigation I found this thread... My use case is exactly as @CreMindES explained: we are triggering release with Slack channel announcement. We immediately catch the thread ID in the channel, and what we need is just inject metadata to annotations before sync. During sync the notification engine has access to the field, and will send update to the thread.