Skip to content

Move ApplicationSetting-related code out of CurrentSetting class

Rutger Wessels requested to merge refactor-current-settings/part-2-uncached into master

What does this MR do and why?

This is a follow-up on !138970 (merged).

Related issue: #417763 (closed)

Currently, we have settings in ApplicationSetting class. These are accessed using Gitlab::CurrentSetting class. With cells, we will have settings that will move from ApplicationSetting to OrganizationSetting. But we want to keep accessing settings using Gitlab::CurrentSetting. So we want to move some specific ApplicationSetting related logic to ApplicationSettingFetcher which was introduced in the previous MR

This MR will move a few methods to ApplicationSettingFetcher. The result is that this class has no dependencies on ApplicationSetting model anymore and can now be extended to support OrganizationSetting, which will be a next MR.

Methods that are now moved to ApplicationSettingFetcher:

  • (private method) uncached_application_settings
  • expire_current_application_settings
  • current_application_settings?

Method code was not changed, only copied.

How to set up and validate locally

Test: Modifying ApplicationSetting

Screen_Recording_2024-01-03_at_17.09.00

Test: Ensure rake tasks can run even without ApplicationSetting available

A suitable Rake task is rake db:setup which will create databases

Run this sequence (NOTE This will wipe out the local development databases)

# Drop all test/development databases (please backup them if you have valuable data)
gdk psql -d postgres -c "drop database gitlabhq_development;"
gdk psql -d postgres -c "drop database gitlabhq_development_ci;"
gdk psql -d postgres -c "drop database gitlabhq_test;"
gdk psql -d postgres -c "drop database gitlabhq_test_ci;"

# Run this rake task: it should run, even without ApplicationSetting in the database
bundle exec rake db:setup

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Rutger Wessels

Merge request reports

Loading