- 01 Sep, 2017 4 commits
-
-
Jacob Vosmaer (GitLab) authored
-
Bob Van Landuyt authored
-
Tiago Botelho authored
-
Jacob Vosmaer (GitLab) authored
-
- 31 Aug, 2017 16 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Alejandro Rodríguez authored
-
Robert Schilling authored
-
Sean McGivern authored
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.
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Maxim Rydkin authored
-
- 30 Aug, 2017 9 commits
-
-
Mike Greiling authored
-
Kim "BKC" Carlbäcker authored
- `Gitlab::Shell.fetch_remote` now takes a `Gitlab::Git::Repository` instead
-
Marc Siegfriedt authored
-
Lin Jen-Shin authored
-
Sean McGivern authored
As we only override in two places, we could just ask for the value rather than the method name.
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Robert Schilling authored
-
- 29 Aug, 2017 11 commits
-
-
Robert Schilling authored
-
Travis Miller authored
-
Travis Miller authored
-
Yorick Peterse authored
This adds a bunch of checks to migrations that may create or drop triggers. Dropping triggers/functions is done using "IF EXISTS" so we don't throw an error if the object in question has already been dropped. We now also raise a custom error (message) when the user does not have TRIGGER privileges. This should prevent the schema from entering an inconsistent state while also providing the user with enough information on how to solve the problem. The recommendation of using SUPERUSER permissions is a bit extreme but we require this anyway (Omnibus also configures users with this permission). Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36633
-
Hiroyuki Sato authored
-
Lin Jen-Shin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-