Commit graph

10 commits

Author SHA1 Message Date
GitLab Bot
564919dfc6 Add latest changes from gitlab-org/gitlab@master 2021-08-11 09:10:00 +00:00
GitLab Bot
0ae8428c8e Add latest changes from gitlab-org/gitlab@master 2021-05-11 21:10:21 +00:00
GitLab Bot
f2dfd9ee81 Add latest changes from gitlab-org/gitlab@master 2020-03-22 15:09:49 +00:00
GitLab Bot
b7dfe2ae40 Add latest changes from gitlab-org/gitlab@master 2019-09-13 13:26:31 +00:00
Lin Jen-Shin
6b0d493350 Introduce ApplicationSettingImplementation yay
So the fake can enjoy it, too. We don't use `prepend`
because that'll require we change `allow_any_instance_of` to
`expect_next_instance_of`, but that's not very easy to do.
We can do that later.
2019-03-19 13:01:37 +08:00
Rémy Coutable
ecb847fd30
Add FakeApplicationSettings#commit_email_hostname
Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-12-19 17:43:12 +01:00
gfyoung
c858f70d07 Enable frozen string for lib/gitlab/*.rb 2018-10-22 07:00:50 +00:00
Stan Hu
70799b05ab Add additional stub methods for FakeApplicationSetting
In a migration spec, a default ApplicationSetting object may fail to
create due to an unknown attribute and fall back to
FakeApplicationSetting.  FakeApplicationSetting appears to be missing a
number of methods that are needed
(https://gitlab.com/gitlab-org/gitlab-ce/issues/47491). This commit adds
the ones needed to make an EE spec pass.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/7543
2018-09-10 22:27:21 -07:00
Stan Hu
183c94dd63 Work around migration specs failing due to repository storages not being selected
Migration specs may be missing a column necessary to create an ApplicationSetting
object, which causes the FakeApplicationSetting to be initialized. However, the
project selects a random repository storage via ApplicationSetting#pick_repository_storage,
which isn't present in the OpenStruct.

To workaround this issues, we add a pick_repository_storage method in
FakeApplicationSetting.
2018-09-10 14:03:21 -07:00
Stan Hu
575dced5d7 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-19 09:54:48 -07:00