GitLab for Slack app integration not working with Cells 1.0

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

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

We'd like need to allow GitLab for Slack app settings to be configured for organization.

The public GitLab for Slack app in the Slack app directory must POST slash commands and other interactions to specific endpoints.

We'd likely need the cells router to route existing slack/trigger API endpoint and integrations/slack/* endpoints to the main cell. This would mean all tenants on the main cell could continue to use the GitLab for Slack app that is in the Slack app directory.

For customers who migrate to another cell, they would need to generate their own GitLab for Slack app for their organization, similar to how instance admins can generate their own 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).

Rejected solutions

Use Socket Mode #416491

GitLab 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.