The pre-release tags are set at the beginning of a release, so it
would be impossible to figure out which version was running if we're
running nightlies.
In that case it's better to still link to the SHA. These versions
don't get deployed to .com.
The second option to this matcher should be an options hash; anything
else is just ignored, which can lead to false positives in tests.
We see one such false positive in the "Learn more" link test in
`spec/features/projects/blobs/blob_show_spec.rb`.
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.
GitLab Bot