Commit Graph

116 Commits

Author SHA1 Message Date
GitLab Bot 2241d988f8 Add latest changes from gitlab-org/gitlab@master 2025-05-08 06:11:11 +00:00
GitLab Bot 5b5481bb3f Add latest changes from gitlab-org/gitlab@master 2025-03-27 15:17:58 +00:00
GitLab Bot 87164ac651 Add latest changes from gitlab-org/gitlab@master 2024-12-10 09:31:19 +00:00
GitLab Bot df697c947a Add latest changes from gitlab-org/gitlab@master 2024-10-29 18:30:01 +00:00
GitLab Bot 6eead8954d Add latest changes from gitlab-org/gitlab@master 2024-07-23 15:33:53 +00:00
GitLab Bot eca41b94ac Add latest changes from gitlab-org/gitlab@master 2024-05-09 12:16:27 +00:00
GitLab Bot c0bc64e25e Add latest changes from gitlab-org/gitlab@master 2024-01-20 00:09:13 +00:00
GitLab Bot b63258f304 Add latest changes from gitlab-org/gitlab@master 2024-01-03 21:13:21 +00:00
GitLab Bot d99f2ee027 Add latest changes from gitlab-org/gitlab@master 2023-12-20 03:20:24 +00:00
GitLab Bot 1f229cdc22 Add latest changes from gitlab-org/gitlab@master 2022-08-09 12:11:57 +00:00
GitLab Bot db19df2373 Add latest changes from gitlab-org/gitlab@master 2022-03-16 15:07:32 +00:00
GitLab Bot 41482e5dce Add latest changes from gitlab-org/gitlab@master 2022-02-14 09:13:38 +00:00
GitLab Bot 6a5b78ac69 Add latest changes from gitlab-org/gitlab@master 2021-12-07 03:12:22 +00:00
GitLab Bot e5c7d631a8 Add latest changes from gitlab-org/gitlab@master 2021-11-15 15:10:57 +00:00
GitLab Bot f4d51a9f71 Add latest changes from gitlab-org/gitlab@master 2021-07-29 15:09:48 +00:00
GitLab Bot a8c1bc6f75 Add latest changes from gitlab-org/gitlab@master 2021-05-25 15:10:33 +00:00
GitLab Bot e5e0589e09 Add latest changes from gitlab-org/gitlab@master 2021-04-26 12:09:44 +00:00
GitLab Bot 2e9f877e8b Add latest changes from gitlab-org/gitlab@master 2021-02-22 09:10:46 +00:00
GitLab Bot d8714cf67c Add latest changes from gitlab-org/gitlab@master 2021-02-02 00:09:14 +00:00
GitLab Bot 01a8b31afe Add latest changes from gitlab-org/gitlab@master 2020-11-16 15:09:23 +00:00
GitLab Bot 2eda658f34 Add latest changes from gitlab-org/gitlab@master 2020-04-15 21:09:18 +00:00
GitLab Bot eb1f5a3e08 Add latest changes from gitlab-org/gitlab@master 2020-02-17 18:09:00 +00:00
Reuben Pereira af4a597d3f Save instance administration project id in DB
- This will make it easy to identify the project even if admins change
the name of the project or move it.
2019-08-07 18:40:36 +00:00
Heinrich Lee Yu aeb67dd489 Upgrade to Rails 5.2
Updates changed method names and fixes spec failures
2019-07-12 10:15:31 +08:00
Rémy Coutable 90718774e1
Use a Gitlab::FakeApplicationSettings when migrations are pending
Signed-off-by: Rémy Coutable <remy@rymai.me>
2019-03-26 23:02:57 +01:00
Lin Jen-Shin 0ff27ce059
Method `create_from_defaults` will never give nil 2018-12-19 11:24:54 +01:00
Lin Jen-Shin cc5099c5ce
Move schema aware defaults to build_from_defaults
This way we can reuse the safe setting
2018-12-19 11:24:54 +01:00
Lin Jen-Shin 1ae28e0e7b
Return fake if and only if there's no database
Because `connect_to_db?` already detects if the table exists or not
2018-12-19 11:24:54 +01:00
Rémy Coutable 71672dfa6a
Return an ApplicationSetting in CurrentSettings
This replaces the use of fake_application_settings with
`::ApplicationSetting.build`_from_defaults. The reason is that
`fake_application_settings` doesn't have the custom accessors that
`ApplicationSetting` has, e.g. `#commit_email_hostname`, thus this
can lead to unexpected `nil` values which comes from the database
column instead of `.default_commit_email_hostname` returned by
`ApplicationSetting#commit_email_hostname`.

Using `::ApplicationSetting.build_from_defaults` should be safe as it
doesn't try to `INSERT` a DB record, in contrary to
`::ApplicationSetting.create_from_defaults` which we used to use, and
which created issues that the introduction of
`fake_application_settings` tried to resolve (575dced5).

Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-12-19 11:24:53 +01:00
gfyoung c858f70d07 Enable frozen string for lib/gitlab/*.rb 2018-10-22 07:00:50 +00:00
Michael Kozono f107bc69e3 Simplify by using Gitlab::SafeRequestStore
These are clear wins.
2018-09-24 12:11:26 -07:00
Stan Hu 855b238361 Simplify setting of in_memory_application_settings 2018-09-10 15:04:27 -07:00
Rémy Coutable 3bf1cd5780
Ensure in-memory application settings are cleared before each test
Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-09-10 11:48:09 +02:00
Lin Jen-Shin 4ee08b77bc Updates from `rubocop -a` 2018-07-09 21:13:08 +08:00
Rémy Coutable 6afe6fa6bc
Make Gitlab::CurrentSettings.current_application_settings return cached settings early if they exist without issuing any DB query
Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-06-07 17:23:49 +02:00
Stan Hu 1bcdd25ce2
Avoid sequential scans loading schema_migrations table when loading application settings
This was causing significant performance problems in production, and this commit
reverts to the original behavior.
2018-06-07 17:23:49 +02:00
Rémy Coutable 2bdf6edefa
Simplify Gitlab::CurrentSettings now that the logic is in CacheableAttributes
Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-05-23 16:14:43 +02:00
Stan Hu 272783be20 Cache table_exists?('application_settings') to reduce repeated schema reloads
Closes #43355
2018-03-15 13:13:00 -07:00
Mario de la Ossa eaada9d706 use Gitlab::UserSettings directly as a singleton instead of including/extending it 2018-02-02 18:39:55 +00:00
Lin Jen-Shin 07d3d44775 Move ModuleWithInstanceVariables to Gitlab namespace
And use .rubocop.yml to exclude paths we don't care,
rather than using the cop itself to exclude.
2017-11-22 17:06:57 +08:00
Lin Jen-Shin 9ac0c76b78 Use StrongMemoize and enable/disable cops properly 2017-11-18 01:01:53 +08:00
Lin Jen-Shin 9ae92b8caa Add cop to make sure we don't use ivar in a module 2017-09-18 21:23:45 +08:00
Sean McGivern 5883ce95ef `current_application_settings` belongs on `Gitlab::CurrentSettings`
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.
2017-08-31 13:38:33 +01:00
Paul Charlton 65eca13f7b Repair Regression caused by - !11573
some changes introduced by 4daa6da540, 26b6e299e1, 17898ce021 were regressed during today's merge conflict resolution of !11573.

This commit serves to reapply those changes.

/cc: @rspeicher @stanhu @mikegreiling
2017-07-11 14:23:51 +08:00
Paul Charlton cb3b4a15e6 Support multiple Redis instances based on queue type 2017-07-11 03:35:47 +00:00
DJ Mountney e643c0db35 Merge branch 'master' into 'catch-redis-address-error'
# Conflicts:
#   lib/gitlab/current_settings.rb
2017-07-10 21:20:52 +00:00
Nick Thomas aeb2869f66 Prevent bad data being added to application settings when Redis is unavailable 2017-07-10 15:40:51 +01:00
DJ Mountney 353af927d2 Add additional error caching for redis when using a tcp address to
connect instead of a socket

This helps with compiling gitlab assets without a redis server (used
during omnibus build)
2017-06-27 21:50:23 -07:00
Stan Hu 03e538b721 Change references from ApplicationSetting to ::ApplicationSetting to make autoload happier
Closes #34047
2017-06-20 23:27:31 -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