delta/gitlab/gitlab-ce.git/spec/views/help, branch docs/https-many-docs-links gitlab.com: gitlab-org/gitlab-ce.git Fix specs to match route changes 2019-05-20T12:21:37+00:00 Dmitriy Zaporozhets dmitriy.zaporozhets@gmail.com 2019-05-20T12:21:37+00:00 70decdc2acb4da895bdd63bb15b46014045af661 Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com> 
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Update gitlab-styles to 2.5.1 2019-01-11T22:59:35+00:00 Jasper Maes jaspermaes.jm@gmail.com 2019-01-11T20:10:55+00:00 4361c92b6a41554ae8a8e4ad7204e8ed82ec7c5c 






Show the commit-sha for pre-release versions
2018-10-02T14:11:32+00:00

Bob Van Landuyt
bob@vanlanduyt.co

2018-10-01T13:59:44+00:00

b09e40624b9fc6a7b4a7b38f174bc66d996e3fd5

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 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.







Link to the tag from a version instead of commit
2018-10-01T09:59:48+00:00

Bob Van Landuyt
bob@vanlanduyt.co

2018-10-01T08:43:46+00:00

18324261097de835628570696594f749e48d3747

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.





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.







Correct usage of the have_link matcher
2018-09-14T20:36:40+00:00

Robert Speicher
rspeicher@gmail.com

2018-09-14T20:36:40+00:00

14a27a4f40d837d5ce690107cf4f97b9907d2b2a

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 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`.







Replace Gitlab::REVISION with Gitlab.revision and handle installations without a .git directory
2018-05-24T08:14:01+00:00

Rémy Coutable
remy@rymai.me

2018-05-24T07:57:54+00:00

d50a80a282b2ca145841774f4be154a977cccfd8

Signed-off-by: Rémy Coutable <remy@rymai.me>





Signed-off-by: Rémy Coutable <remy@rymai.me>







Added ssh fingerprint, gitlab ci and pages information in an instance configuration page
2017-10-25T20:51:26+00:00

Francisco Lopez
fjsanpedro@gmail.com

2017-08-24T14:34:36+00:00

294f40e2c8f51239bfa0e3514e7fe4f3c8ae00cb

Closes #25142





Closes #25142







`current_application_settings` belongs on `Gitlab::CurrentSettings`
2017-08-31T12:38:33+00:00

Sean McGivern
sean@gitlab.com

2017-08-31T09:47:03+00:00

5883ce95efcc4cc04f949f9b4e66d73fbede94e2

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.





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.







Make the revision on the `/help` page clickable
2017-06-09T08:35:42+00:00

Toon Claes
toon@gitlab.com

2017-06-08T13:43:06+00:00

7188b4d83989dcfcc672f88e19d1ddb550b4917a

For quicker access, add hyperlink to the gitlab.com commits page for the current
REVISION of GitLab.





For quicker access, add hyperlink to the gitlab.com commits page for the current
REVISION of GitLab.







Allow non-admin users to see version information
2015-09-23T21:18:15+00:00

Robert Speicher
rspeicher@gmail.com

2015-09-23T21:18:15+00:00

45824aabc634e06d9f7dd853e573c153b7bf9a78

We want users to know what features they have available (and to pressure
their admins to upgrade).





We want users to know what features they have available (and to pressure
their admins to upgrade).