| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This will result in a 404 when running an unreleased security patch
while still allowing users to find the commit when it is made available.
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
|
| |
without a .git directory
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
| |
configuration page
Closes #25142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
For quicker access, add hyperlink to the gitlab.com commits page for the current
REVISION of GitLab.
|
|
|
|
|
| |
We want users to know what features they have available (and to pressure
their admins to upgrade).
|
| |
|
|
|