Improve how we control availability of integrations (through feature flags etc.)

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

• Close this issue

Summary

This issue was prompted by the discussion at !80931 (comment 853224992) and !80931 (comment 853224266).

There isn't really a good way to globally control whether an integration is available or not. This is especially important when developing new integrations, and we want to gate them behind a feature flag.

With Datadog I think we used Project#disabled_integrations but that only covers the project level.

Maybe a better place would be Integration.available_integration_names, but that also doesn't cover all of the REST and GraphQL APIs (see e.g. #338796).

@alexkalderimis also pointed out that there could be a need by instance admins to control availability of integrations:

I wonder if there is demand for admins to lock down the set of available integrations - some kind of instance_enabled? flag somewhere would both support the availability of integrations and allow admins to restrict the integration set they want to offer.

Improvements

1. Identify the best approach to check the availability of integrations.
2. Make sure all endpoints (contollers + API) go through this check.

Maybe we can focus on point 1 in this issue, and then create follow-up issues for the remaining work in point 2.

Involved components

Controllers:

• app/controllers/projects/services_controller.rb
• app/controllers/groups/settings/integrations_controller.rb
• app/controllers/admin/integrations_controller.rb
• app/controllers/concerns/integrations/actions.rb
  • This concern is only used by the group and admin controllers, but not in projects.

API endpoints:

• lib/api/integrations.rb
• app/graphql/resolvers/projects/services_resolver.rb
• app/graphql/types/projects/service_type_enum.rb

Optional: Missing test coverage

We should extend our request tests for all relevant endpoints to consider availability.