Age | Commit message (Collapse) | Author | |
---|---|---|---|
2018-02-02 | use Gitlab::UserSettings directly as a singleton instead of ↵ | Mario de la Ossa | |
including/extending it | |||
2018-01-31 | Enable RuboCop Style/RegexpLiteral | Takuya Noguchi | |
2017-08-31 | `current_application_settings` belongs on `Gitlab::CurrentSettings` | Sean McGivern | |
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-15 | Fix race condition with dispatcher.js | Phil Hughes | |
The dispatcher was trying to create a new instance of a class that is loaded in a file after main.js which would cause the filtered search to not work on issues. This would only happen on the first load when the JS is not cached. If the JS is cached, then everything will be fine. | |||
2017-02-22 | added specs for version check image | Luke "Jared" Bennett | |