Include Registration Features check in SSoT method for license check
Problem
Currently we have created many issues in Registration Features (&8977 - closed) to get teams to move more features into Usage Pings. These instructions are complex and have introduced a number of duplications and inconsistencies in our codebase:
- Where we had
License.feature_available?
we now haveLicense.feature_available?(:the_features) || ::GitlabSubscriptions::Features.usage_ping_feature?(:the_feature)
- In some cases we introduced a different pattern like
lib/gitlab/registration_features.rb
which is inconsistent with the other feature checks. - We don't know whether we fixed all license checks because some of they may be dynamic (using metaprogramming). This could introduce bugs and inconsistencies.
- This pattern is not future-proof because we now have to always use the 2 conditions everywhere from now on.
This represents a lack of SSoT.
Goal
Transform the License.feature_available?
check into the SSoT check that returns if a feature is available at instance level, whether it's from the purchased license/tier or from the instance admin having enabled Usage Pings (so you get extra features for that).
Cyclical dependency problem
We know that we previously attempted to incorporate usage ping feature check inside License.feature_available?
but we decided not to do that because of some cyclical dependencies:
flowchart LR
Gitlab::CurrentSettings --> ApplicationSetting --> Gitlab::ImportSources --> License.feature_available? --> Gitlab::CurrentSettings
However, these cyclical dependencies are located within ApplicationSetting
when using License.feature_available?
.
We should be able to skip the check for usage ping features due to cyclical dependencies in these few instances of the codebase. This way we have made the problem of cyclical dependencies explicit rather than implicit.
The cyclical dependencies are not wide-spread and they are specifically located within an area of code that deals with initialization. We can deal with cyclical dependencies later if we have a good way to identify them in code. This should not prevent us from using a much more common pattern for license check and making it the SSoT.
Iterations
-
Make License.feature_available?
the SSoT for license checks -
[Feature flag] Rollout of `feature_available_ch... (#422614 - closed) • Fabio Pitino • 16.5 -
Update instructions in the existing issues -
Cleanup unnecessary code in lib/gitlab/registration_features.rb
and unnecessary conditions added so far -
Explicitly define which features cannot easily be moved to usage pings (like custom_project_templates
due to cyclical dependencies)