In #358872 (closed) we delivered an MVC for self-managed to install, and update, their own copies of the GitLab for Slack app.
The MVC relies on some manual steps, particularly when it comes to updating their Slack app with the new manifest.
Ideally, we could automate as much of this process as possible.
Proposal
There is no concrete proposal yet. We should look into Slack App Manifest APIs and determine how we could update their Slack app's manifest in the most automated flow possible.
If you are unsure about the correct group, please do not leave the issue without a group label, and refer to
GitLab's shared responsibility functionality guidelines
for more information on how to triage this kind of issue.
These tokens allow us to admin any Slack app in a Slack workspace on behalf of a Slack workspace admin, which is a different (and higher) level of privilege than the "bot" tokens we currently capture and for interacting with the Slack API. The "bot" tokens are used for API calls for things like the Slack notifications feature (search the codebase for Slack::API for all uses).
See token types for a description of the differences.
The "configuration" tokens also expire after 12 hours, unless you refresh them. The "bot" tokens live foreever.
Part of this issue is to consider how we capture these, and what the ideal (iterative) UX should be, and then we can better weigh the issue depending on what we decide.
Here are some thoughts:
We can give GitLab instance admins the choice of updating their Slack app manually or giving us a Slack "configuration" token for us to do it automatically, because lots of admins might not want to give us such a token (it allows us to manage any Slack app in their workspace).
We need to consider how far we want to go with automation in this iteration. I can see two possibilities:
For this iteration, we do not try to keep the tokens alive by refreshing them. Each time the Slack app should be updated, an instance admin would still need to decide to update it, but now would have the option to update via a token instead of manually. The current fully-manually (non-token) flow for an admin updating their Slack app is actually reasonably simple and hard for them to get wrong, so this iteration would actually add relatively little value to their current experience. To the point where I feel it's likely to not be worth the implementation unless customers really tell us the current manual process is hard (seems unlikely - there are current no thumbs-up on this issue?)
For this iteration, we aim for fully automated Slack app updates (where possible). We persist the token and its refresh token, and perpetually refresh it via a worker. Over many months, we may lose the token's freshness because the user is no longer a Slack admin (I assume the refresh would fail), or during the course of a particular 12 hour period the refresh endpoint was unable to be reached by the instance (say, the GitLab instance is taken down for maintenance and we lose the window of time, or a networking reason means the calls are blocked for a period of time, or ....). We would trigger fully automated updates of Slack apps for instances (not requiring any manual action of their own) - for example, we add a data migration that kicked off a worker to update their Slack app within a particular release when we knew their Slack app should be updated. It would be a problem if we had previously captured a token and we had failed to keep it alive (due to the many possible reasons) as an instance admin would understand that their Slack app should be auto-updating and it wouldn't be. All of this adds a lot to the weight and overall complexity of this issue.
Either option requires a little bit of extra implementation thought before we can make this workflowready for development . Let me know your thoughts!
@.luke how often Slack app would need updating by admin?
We can give GitLab instance admins the choice of updating their Slack app manually or giving us a Slack "configuration" token for us to do it automatically, because lots of admins might not want to give us such a token (it allows us to manage any Slack app in their workspace).
This feels like we might not try to automate after all.
@m_frankiewicz It's difficult to answer properly. So far, an admin would never have needed to update their Slack app since we released the feature of Slack app for self-managed. This is mostly due to how the GitLab for Slack app has not been a priority since we released that feature, though.
To give you a better answer: If we build on top of existing functionality (for example, we add a new notification type, or support something new that the /gitlab slash command does in GitLab) then we don't need to update the Slack app. This is because all of the configuration, including the permission scopes we've selected, of the Slack app will work fine for those kinds of extentions. If we add some functionality that is a new capability for our Slack app (and it can be hard to define a list of new...) then we often need to update the Slack app to enable that new capability.
For example, link unfurling would require a Slack app update because we would require new permission scopes (at least, possibly other things).
We have existing code that lets us check what scopes have been permitted for a token, so we can use that to gracefully degrade any GitLab -> Slack calls. Any new functionality that goes from Slack -> GitLab only happens after the Slack app is updated. So in both cases, if someone hasn't updated their Slack app, we can essentially just treat it like a feature that is toggled off.