Adding deprecation messages

We store a list of deprecations associated with it in the list method of Gitlab::Deprecations class If a configuration has to be deprecated, it has to be added to that list with proper details.


deprecations = [
            config_keys: %w(gitlab postgresql data_dir),
            deprecation: '11.6',
            removal: '14.0',
            note: "Please see for how to use postgresql['dir']"
            config_keys: %w(gitlab sidekiq cluster),
            deprecation: '13.0',
            removal: '14.0',
            note: "Running sidekiq directly is deprecated. Please see for how to use sidekiq-cluster."


config_keys represents a list of keys, which can be used to traverse the configuration hash available from /opt/gitlab/embedded/nodes/{fqdn}.json to reach a specific configuration. For example %w(mattermost log_file_directory) means mattermost['log_file_directory'] setting. Similarly, %w(gitlab nginx listen_addresses) means gitlab['nginx']['listen_addresses']. We internally convert it to nginx['listen_addresses'], which is what we use in /etc/gitlab/gitlab.rb.


deprecation is where you set the <major>.<minor> version that deprecated the change. Starting in that version, running gitlab-ctl reconfigure will warn that the setting is being removed in the removal version, and it will display the provided note.


removal is where you set the <major>.<minor> version that will no longer support the change at all. This should almost always be a major release. The Omnibus package runs a script at the beginning of installation that ensures you don’t have any removed configuration in your settings. The install will fail early, before making any changes, if it finds configuration that is no longer supported.


note is part of the deprecation message provided to users during gitlab-ctl reconfigure. Use this area to inform users of how to change their settings, often by linking to new documentation, or in the case of a settings rename, telling them what the new setting name should be.