Reorganize settings
Created by: riyad
- Reorganize the setting options in
config/gitlab.yml - Explian settings better
- Clean up the settings initializer
- Define default values for settings without overriding all option methods
- Update all uses of the configs
Merge request reports
Activity
34 34 def gravatar_icon(user_email = '', size = nil) 35 35 size = 40 if size.nil? || size <= 0 36 36 37 if Gitlab.config.disable_gravatar? || user_email.blank? 34 34 def gravatar_icon(user_email = '', size = nil) 35 35 size = 40 if size.nil? || size <= 0 36 36 37 if Gitlab.config.disable_gravatar? || user_email.blank? Created by: dzaporozhets
@vsizov +1
I am not sure why we need this changes. We need to force users rewrite their config with new one and setup again for uncertain advantages.
By Administrator on 2012-12-11T08:47:04 (imported from GitLab project)
By Administrator on 2012-12-11T08:47:04 (imported from GitLab)
Created by: riyad
I agree this is a "risky" proposal, but it has merit. :)
- Config names in
gitlab.ymland inSettingsare now better correlated ;) No ugly overriding and renaming all settings methods. Settings are the same in the config and in the code! - It groups most settings (except "auth") under "gitlab" which were separated under "app" and "email" etc..
- It renames "git_host" to "gitolite" to make it clearer
- It renames "base_path" to "repos_path". The funny thing is in
gitlab.ymlthis is undergit_host.base_pathbut if you access the settings it'sconfig.git_base_pathbut actually it's "Gitolite's repo path".
- It prefixes some options with "ssh_" to make it clear Gitolite uses them for SSH access
- It streamlines things like "ldap.enable" and "disable_gravatar"
to name just a few advantages ;)
By Administrator on 2012-12-11T12:27:18 (imported from GitLab project)
By Administrator on 2012-12-11T12:27:18 (imported from GitLab)
- Config names in
Created by: riyad
Motivation: I got confused several times, when working on the documentation and the status task, that there is a difference between how things are named in the config file, in the Settings object and in the documentation. So I tried to leverage the opportunity (major version changes are great for this ;) ) and propose a "correction".
By Administrator on 2012-12-11T12:30:29 (imported from GitLab project)
By Administrator on 2012-12-11T12:30:29 (imported from GitLab)
Created by: rtripault
My 2 cents as an "end user who likes painless upgrades and is ruby new comer"
If it helps to better understand what's behind the scene, that's clearly a great addition. Furthermore, upgrading to Gitlab v4 will not really be painless (namespaces changing a lot of things!). So while having a "not-finger-in-the-noze" update, let's make it happen only once :)
But that might some more documentation…
I hope it does make sense
By Administrator on 2012-12-11T13:31:23 (imported from GitLab project)
By Administrator on 2012-12-11T13:31:23 (imported from GitLab)
Created by: sodabrew
Would you also consider the refactoring of omniauth settings from PR #1491 -- and we should certainly add a deprecated configuration warning to help show users what changes to make.
By Administrator on 2012-12-14T20:57:51 (imported from GitLab project)
By Administrator on 2012-12-14T20:57:51 (imported from GitLab)
Created by: riyad
Rebased and updated:
- backup and gravatar are toplevel configs now
- used automated conversion for f1d38db
- "manual" changes are in 9513969
- fixed
app/helpers/application_helper.rb: it usesifagain
By Administrator on 2012-12-15T01:19:40 (imported from GitLab project)
By Administrator on 2012-12-15T01:19:40 (imported from GitLab)
Created by: moregeek
As @Riyad mentioned above it sometimes hard to check e.g what option in the config is accessabel with which method from the initializer - therefore +1.
The only thing I would sugest is to add depreciation warnings to the old methods and add new ones instead... And after refactoring the code the old methods can be removed...
By Administrator on 2012-12-15T18:59:09 (imported from GitLab project)
By Administrator on 2012-12-15T18:59:09 (imported from GitLab)
Created by: dzaporozhets
I've reched new gitlab.yml and may say it becomes more obvious. The question is: "when apply this one?" We may dont want it for 4.0 cause we tested a lot of functionality and it requires from us recheck a lot of cases (like LDAP, Omniauth etc) which is not covered by tests.
And asking users for 4.1 to rewrite their configs is also not good. Update from 4.0 to 4.1 should be very easy cause users may be tired of complicated updates (since 2.9 every update was not so easy)
So 4.0 or 4.1 or leave for future?
Personally I'd like to apply it to 4.0 if @Riyad can promise me its doesnt break something :)
By Administrator on 2012-12-16T17:33:47 (imported from GitLab project)
By Administrator on 2012-12-16T17:33:47 (imported from GitLab)
Created by: riyad
@moregeek Ilike your idea. Change the config file, but keep the old
Settings.foomethods and add deprecation warnings to them. So we can change the config file, but the internal API stays compatible.By Administrator on 2012-12-16T17:45:40 (imported from GitLab project)
By Administrator on 2012-12-16T17:45:40 (imported from GitLab)
Created by: riyad
Rebased and updated.
- put back all the old settings methods
- updated them to use the new settings format
- added deprecation warnings, so they show up in logs
This should allow us to change the
gitlab.ymland not break oldSettings.foocalls.By Administrator on 2012-12-17T17:00:32 (imported from GitLab project)
By Administrator on 2012-12-17T17:00:32 (imported from GitLab)
Created by: dzaporozhets
I will get
Missing setting 'gitlab' in /home/dzaporozhets/projects/gitlab/gitlabhq/config/gitlab.ymlso its still incompatible with old settingsBy Administrator on 2012-12-19T14:57:35 (imported from GitLab project)
By Administrator on 2012-12-19T14:57:35 (imported from GitLab)
Created by: riyad
Rebased and updated once more. :)
- it can new take the old and the new config file format
- using an old file will log deperecation warnings
- updated the gitlab:check task to check for outdated (i.e. pre 4.0) config files
By Administrator on 2012-12-20T16:31:12 (imported from GitLab project)
By Administrator on 2012-12-20T16:31:12 (imported from GitLab)
Created by: dzaporozhets
@Riyad thank you :)
By Administrator on 2012-12-20T17:46:37 (imported from GitLab project)
By Administrator on 2012-12-20T17:46:37 (imported from GitLab)
