delta/gitlab/gitlab-ce.git - gitlab.com: gitlab-org/gitlab-ce.git

	Commit message (Collapse)	Author	Age	Files	Lines
*	`current_application_settings` belongs on `Gitlab::CurrentSettings`	Sean McGivern	2017-08-31	1	-0/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	Enable Style/DotPosition Rubocop :cop:	Grzegorz Bizon	2017-06-21	1	-2/+2
\|
*	Fix login tests for crowd to use #crowd.	Bryce Johnson	2016-10-18	1	-2/+2
\|
*	Remove provider path, replace with dynamic path.devise-deprecations	Connor Shea	2016-08-03	1	-1/+1
\|
*	Move "I should see Crowd login form" feature to a view specrs-crowd-form-view-spec	Robert Speicher	2016-02-24	1	-0/+37
	We were doing all kinds of code gymnastics to "enable" Crowd in the feature spec and this would sometimes cause a transient failure. Really what it's testing is if the Crowd login form shows when Crowd's enabled, so this is much better suited to a view spec.