gitlab-org--gitlab-foss/spec/factories/application_settings.rb

# frozen_string_literal: true

FactoryBot.define do
  factory :application_setting do
    default_projects_limit { 42 }
    import_sources { [] }
  end
end
Add frozen_string_literal to spec/factories Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758 2019-07-25 01:11:48 -04:00			`# frozen_string_literal: true`

Replace factory_girl_rails with factory_bot_rails I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md) and ran these two commands: ``` grep -e FactoryGirl */.rake */.rb -s -l \| xargs sed -i "" "s\|FactoryGirl\|FactoryBot\|" grep -e factory_girl */.rake */.rb -s -l \| xargs sed -i "" "s\|factory_girl\|factory_bot\|" ``` Signed-off-by: Rémy Coutable <remy@rymai.me> 2017-12-13 19:13:44 -05:00			`FactoryBot.define do`
If migrations are pending, make CurrentSettings use existing values and populate missing columns with defaults master was failing because `ApplicationSetting.create_from_defaults` attempted to write to a column that did not exist in the database. This occurred in a `rake db:migrate` task, which was unable to perform the migration that would have added the missing column in the first place. In 9.3 RC2, we also had a bug where password sign-ins were disabled because there were many pending migrations. The problem occurred because `fake_application_settings` was being returned with an OpenStruct that did not include the predicate method `signup_enabled?`. As a result, the value would erroneously return `nil` instead of `true`. This commit uses the values of the defaults to mimic this behavior. This commit also refactors some of the logic to be clearer. 2017-06-17 10:35:30 -04:00			`factory :application_setting do`
Add latest changes from gitlab-org/gitlab@master 2019-10-01 20:06:26 -04:00			`default_projects_limit { 42 }`
Add latest changes from gitlab-org/gitlab@master 2020-03-24 11:08:44 -04:00			`import_sources { [] }`
If migrations are pending, make CurrentSettings use existing values and populate missing columns with defaults master was failing because `ApplicationSetting.create_from_defaults` attempted to write to a column that did not exist in the database. This occurred in a `rake db:migrate` task, which was unable to perform the migration that would have added the missing column in the first place. In 9.3 RC2, we also had a bug where password sign-ins were disabled because there were many pending migrations. The problem occurred because `fake_application_settings` was being returned with an OpenStruct that did not include the predicate method `signup_enabled?`. As a result, the value would erroneously return `nil` instead of `true`. This commit uses the values of the defaults to mimic this behavior. This commit also refactors some of the logic to be clearer. 2017-06-17 10:35:30 -04:00			`end`
			`end`