Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

React on slack notification with merge request status #17

Closed
eher-werkspot opened this issue Aug 10, 2021 · 5 comments
Closed

React on slack notification with merge request status #17

eher-werkspot opened this issue Aug 10, 2021 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@eher-werkspot
Copy link
Contributor

We could have a feature to react to the notification message depending on the status of the merge request:

⛏️ draft merge request
⚙️ pipeline running
❌ pipeline failed
🟢 pipeline is ok
💬 has threads to be resolved
✅ merge request approved
🚀 merged

@eher-werkspot eher-werkspot added the enhancement New feature or request label Aug 10, 2021
@EHER
Copy link
Contributor

EHER commented Sep 17, 2021

We can use this slack method: https://api.slack.com/methods/reactions.add

It requires the timestamp of the original message as a parameter.

@EHER
Copy link
Contributor

EHER commented Mar 19, 2022

The message is identified on a Slack channel by its timestamp (sometimes called ts).

We are currently using the Incoming WebHook to notify the channels and this way we are not getting the timestamp back. It's also not possible to send the timestamp on the payload.

So before starting on the reaction itself, we have to find a way to find get the timestamp of a merge request sent earlier.

One way would be by searching on each channel for the message related to the merge request. The benefit of this approach is the avoid dependency on storage. We rely on the services we already have.

Another way would be to change the way we send the message to save the channel and timestamp to use later. This way we have a history of notification but may require some extra service to keep this history available for multiple instances of the application. Redis could be a candidate to keep the history.

@malukenho
Copy link
Member

The configuration of turbo-enigma is getting complicated because users need to create an app in the slack organisation to have a usable token to search messages and react to them.

As we discussed in our slack channel, we could make use of some key/value storage to save the timestamp information. Slack uses the timestamp of each message as a UNIQID, so, if we have the timestamp information and the URL of the merge request saved somewhere, we could refer to it in future updates to the MR quite easily.

@malukenho malukenho self-assigned this Jul 7, 2022
@malukenho malukenho pinned this issue Jul 7, 2022
@malukenho
Copy link
Member

Sadly, we will have to get more information from other end-points. What we can cover with the current implementation:

  • ✅ merge request approved
  • 🚀 merged

Pending:

  • ⛏️ draft merge request
  • ⚙️ pipeline running
  • ❌ pipeline failed
  • 🟢 pipeline is ok
  • 💬 has threads to be resolved

I particularly find the pipeline statuses helpful to have.

@malukenho
Copy link
Member

#44 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

3 participants