GitLab for Slack app integration not working with Cells 1.0
About
This issue was created from an investigation issue #460196 (closed).
Problem
All of the non-notification-features of the GitLab for Slack app integration work by Slack sending a request to our API when a user performs certain actions within their Slack workspace. These features are when the user:
- Enters a
/gitlab
slash command - Opens the the App Home view
- Uses incident management for Slack https://docs.gitlab.com/ee/operations/incident_management/slack.html
For each type of event (example, Slash commands) a Slack app can only be configured to send to one endpoint.
For example, the endpoint to receive Slash Commands is /api/v4/slack/trigger
.
There is nothing in the endpoint routes that would allow the Cells router to know which cell to route to.
Proposed solution: Use Organization settings
The public GitLab for Slack app in the Slack app directory would continue to work for the main cell only.
Customers who migrate to another cell would need to generate their own GitLab for Slack app for their organization, similar to how instance admins can generate their own Slack apps.
This is very related to the feature issue #424190 which would also allow people to make their own Slack apps for their groups and projects. The feature for organization-level custom GitLab for Slack apps should not preclude our ability to iterate later to support group and project-level custom GitLab for Slack apps.
- The Cells router would route
/api/v4/slack/trigger
to the main cell. Main cell groups and projects could use the public Slack app distributed in the Slack app directory. - We would support organizations generating a custom Slack app and saving that app's secrets within the organization-level settings.
- On secondary cells, the GitLab for Slack app integration would be disabled for a group/project unless its organization had been configured with one.
We would support organization-level API endpoints for Slack (for example, the slash commands endpoint):
/api/v4/organizations/:organization_id/integrations/gitlab-slack-application/slash-command
(Note, there are several other Slack-related endpoints besides the one to handle Slash Commands (see API::Integrations::Slack::
namespace).
Downsides:
- The big downside is mentioned here #424190 (comment 1897098408) which is that each Organization's custom Slack app would need to be updated (in Slack) whenever we make an update to the Slack app itself. We've explored the idea of automating this, but the automation scenario currently doesn't appear to be much more attractive that the entirely manual scenario #401920 (comment 1898579020).
Future:
In future, after #424190 we would have:
/api/v4/organizations/:organization_id/integrations/gitlab-slack-application/slash-command
/api/v4/groups/:group_id/integrations/gitlab-slack-application/slash-command
/api/v4/projects/:project_id/integrations/gitlab-slack-application/slash-command
In that feature issue, the proposal is to use the Cascading Settings framework #424190 (comment 1954001220), however, organization settings are not part of the cascading settings framework currently.
If organization settings were to become part of the Cascading Settings framework later (which seems logical!) this would work nicely with #424190. If it doesn't we could still do a double-lookup of Organization setting + regular cascading settings to obtain the Slack app secrets for the project or group.
Rejected solutions
#416491
Use Socket ModeGitLab backend would connect to Slack via websocket to receive events rather than have Slack post them to an API endpoint. However, each socket connection can receive any event for the app, so we continue to have the same problem. It would also require new infrastructure to maintain stable websocket client on the backend.