Fixed cyclical dependency of `custom_project_templates` feature check
What does this MR do and why?
There is plan to move custom_project_templates
feature to Registration Features but currently this feature is blocked by the cyclical dependency as License.feature_available?
has a cyclical dependency with ApplicationSetting
:
Creating default ApplicationSetting
-> validates import_sources
-> checks License.feature_available?(:custom_project_templates)
-> verifies GitlabSubscriptions::Features.usage_ping_feature?(feature)
-> verifies Gitlab::CurrentSettings.usage_ping_features_enabled?
-> will try create default app settings again as it does not exist yet.
-
To fix that we append
on: :update
to thevalidates_each :import_sources
so that we don't validate that at creation asApplicationSetting.create_from_defaults
already provides valid initial values. -
Applied additional fix for
custom_project_templates_group_id
method to prevent further cyclical dependencies. The default value forcustom_project_templates_group_id
isnil
so swapping the condition should skipcustom_project_templates_enabled?
check and avoid cyclical dependency. -
Removed empty
FEATURES_NOT_SUPPORTING_USAGE_PING
as not required anymore.
How to set up and validate locally
Existing spec that verifies that:
Next existing specs should not fail:
spec/lib/gitlab/current_settings_spec.rb
ee/spec/models/application_setting_spec.rb
bundle exec spring rspec spec/lib/gitlab/current_settings_spec.rb ee/spec/models/application_setting_spec.rb
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #423237 (closed)