delta/gitlab/gitlab-ce.git/app/models/application_setting.rb, branch performance-bar-sql

Merge branch 'prevent-creating-multiple-application-settings' into 'master'

2017-10-17T13:53:42+00:00

Prevent creating multiple ApplicationSetting by forcing it to always have id=1

Closes #34728

See merge request gitlab-org/gitlab-ce!14718

Allow configuring the circuitbreaker through the API and UI

2017-10-17T09:50:32+00:00

Prevent creating multiple ApplicationSetting by forcing it to always have id=1

2017-10-16T08:19:18+00:00

Merge branch 'housekeeping_settings' into 'master'

2017-09-12T12:20:40+00:00

Allow to use same periods for housekeeping tasks

Closes #34981

See merge request !13711

Allow to use same periods for housekeeping tasks

2017-09-11T15:41:07+00:00

This enables skipping a lesser housekeeping task
(incremental or full repack) by consistently
scheduling a higher task (respectively full repack or gc)
with the same period.
Cf. #34981

Read import sources from setting at first initialization

2017-09-09T11:44:56+00:00

More review comments

2017-08-30T20:20:00+00:00

Move the key restriction validation to its own class

2017-08-30T19:50:44+00:00

Address review comments

2017-08-30T19:50:44+00:00

Rework the permissions model for SSH key restrictions

2017-08-30T19:50:44+00:00

`allowed_key_types` is removed and the `minimum__bits` fields are
renamed to `_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.

This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.

As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.