| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'jimmykarily/gitlab-ce-notify_current_user_when_merging_an_mr_after_build_succeeds' into 'master'
Notify current_user about automatic merge after successful build
It enables notifications to the initiator of a merge when the MR is flagged as "Merge when build succeeds".
Because when running Builds, quite some time passes between the user's
action and the actual Merge so it is a good thing to notify the
initiator of the Merge when it actually happens.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14409
See merge request !6534
|
| | |
| |
| |
| | |
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/14409
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
'21983-member-add_user-doesn-t-detect-existing-members-that-have-requested-access' into 'master'
Resolve "`Member.add_user`doesn't detect existing members that have requested access"
## What does this MR do?
This merge request handle the case when an access requester is added to a group or project (via the members page or the API).
In `Member.add_user`, if an access requester already exists, we simply accept their request (and set the `created_by`, `access_level` and `expires_at` attributes if given).
## Are there points in the code the reviewer needs to double check?
I've taken the opportunity to cleanup the whole `{Group,Project}Member.add_user*` methods since it was quite a mess.
## What are the relevant issue numbers?
Closes #21983
See merge request !6393
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changes include:
- Ensure Member.add_user is not called directly when not necessary
- New GroupMember.add_users_to_group to have the same abstraction level as for Project
- Refactor Member.add_user to take a source instead of an array of members
- Fix Rubocop offenses
- Always use Project#add_user instead of project.team.add_user
- Factorize users addition as members in Member.add_users_to_source
- Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects
- Destroy any requester before adding them as a member
- Improve the way we handle access requesters in Member.add_user
Instead of removing the requester and creating a new member,
we now simply accepts their access request. This way, they will
receive a "access request granted" email.
- Fix error that was previously silently ignored
- Stop raising when access level is invalid in Member, let Rails validation do their work
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
New `Members::RequestAccessService`
Part of #21979.
See merge request !6265
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
into 'master'
Changed compare dropdowns to dropdowns with search input
## What does this MR do?
This changes the compare dropdowns from text inputs, that when clicked, open a dropdown of branches/tags to dropdowns that have a dropdown toggle and an isolated search input.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
This was needed to fix the poor UX highlighted in #22221, where opening the dropdown showed an initially filtered set of results because the dropdown toggle was the dropdown filter itself. The compare page is always loaded with `master` as each branch/tag selection, so when opening the dropdown, it would only show results matching `master`.
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #22221
See merge request !6550
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Updated compare specs
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Updated diff toggle targets and added icon
## What does this MR do?
Adds the new diff toggle icon and alters the toggle targets.
User can now click on the file header bar _(where no other elements are above it, apart from the icon)_ and the `Click to expand` link to expand the diff and no where else.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
#### Gif
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #21369
Closes #20326
See merge request !6183
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Updated tests
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Added tests
Added awesomeeeeee icons
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add missing values to linter (`only`, `except`) and add new one `Environment`
Closes #21744
See merge request !6276
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Before rendering `show` template we close open merge request without source project. This way there is no need to render `invalid` template. I think that it's better solution than !6383
See merge request !6478
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Take filters in account in issuable counters
## What does this MR do?
This merge request ensure we display issuable counters that take in account all the selected filters, solving #15356.
## Are there points in the code the reviewer needs to double check?
There was an issue (#22414) in the original implementation (!4960) when more than one label was selected because calling `#count` when the ActiveRecordRelation contains a `.group` returns an OrderedHash. This merge request relies on [how Kaminari handle this case](https://github.com/amatsuda/kaminari/blob/master/lib/kaminari/models/active_record_relation_methods.rb#L24-L30).
A few things to note:
- The `COUNT` query issued by Kaminari for the pagination is now cached because it's already run by `ApplicationHelper#state_filters_text_for`, so in the end we issue one less SQL query than before;
- In the case when more than one label are selected, the `COUNT` queries return an OrderedHash in the form `{ ISSUABLE_ID => COUNT_OF_SELECTED_FILTERS }` on which `#count` is called: this drawback is already in place (for instance when loading https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&state=all&utf8=%E2%9C%93&label_name%5B%5D=bug&label_name%5B%5D=regression) since that's how Kaminari solves this, **the difference is that now we do that two more times for the two states that are not currently selected**. I will let the ~Performance team decide if that's something acceptable or not, otherwise we will have to find another solution...
- The queries that count the # of issuable are a bit more complex than before, from:
```
(0.6ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('opened','reopened')) [["project_id", 2]]
(0.2ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('closed')) [["project_id", 2]]
(0.2ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 [["project_id", 2]]
```
to
```
(0.7ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND ("issues"."state" IN ('opened','reopened')) AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
(0.5ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND ("issues"."state" IN ('closed')) AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
(0.5ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
```
- We could cache the counters for a few minutes? The key could be `PROJECT_ID-ISSUABLE_TYPE-PARAMS`.
A few possible arguments in favor of "it's an acceptable solution":
- most of the time people filter with a single label => no performance problem here
- when filtering with more than one label, usually the result set is reduced, limiting the performance issues
## What are the relevant issue numbers?
Closes #15356
See merge request !6496
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |/ / / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Expose the Koding application settings in the API
## Why was this MR needed?
When saving the GitLab application secrets in Koding, and authorising your admin user to have access to the UI, we want to let Koding enable the integration, and populate the url in GitLab for the user.
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22705
See merge request !6555
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This will allow the Koding app to enable the integration itself once is has authorized an admin user using the application secrets.
|
| |\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This MR fixes a bug that unnecessary escapes reserved HTML characters for Milestone's title. See #22452.
## Are there points in the code the reviewer needs to double check?
- Unescaping of sanitized milestone title before it is being stored in the database. See `Milestone#title` and a private method called `Milestone#sanitize_title`
- Sufficient tests were added (Model and API tests were modified/added).
## Why was this MR needed?
To allow reserved HTML characters in a milestone's title, such as "PHP migration 5.6 -> 7.0". The text appears in 'milestones' and in a dropdown during issue creation, issue list, and in another dropdown for issue filter.
Closes #22452
See merge request !6533
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
in db as unescaped.
Updating test value for milestone title
Adding API test for title with reserved HTML characters.
Updating changelog
Adding the MR number for fixing bug #22452.
removing duplicate line
Updating MR number.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Closes todos for a merge request when the MR is accepted via the API by the MR assignee.
## Are there points in the code the reviewer needs to double check?
Please review refresh service test changes to see if they are correct - I think in those cases, the todos should actually be cleared instead of left pending.
## Why was this MR needed?
To make the API behavior consistent with the UI behavior (accepting your own MRs closes the todo item and prevents them from piling up).
Closes #22477
See merge request !6486
|
| | |/ / / / / / / |
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
New `AccessRequestsFinder`
Part of #21979.
## Does this MR meet the acceptance criteria?
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !6268
|
| | | |_|_|_|/ /
| |/| | | | |
| | | | | | |
| | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix broken repo errors in the UI
This should prevent repo errors (or 404s) in the UI, together with https://gitlab.com/gitlab-org/gitlab_git/merge_requests/124
The `exists?` cache is now expired if the repo gets broken.
Related MR: https://gitlab.com/gitlab-org/gitlab_git/merge_requests/124
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20501
See merge request !6491
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix grammar and typos in Runners pages
_Originally opened at !1791 by @axil._
- - -
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !6547
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Expose project share expiration_date field on API
closes #22382
See merge request !6484
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Upgrade Devise from 4.1.1 to 4.2.0.
This fixes an issue with Rails 5 and brings us up-to-date with the latest Devise release. It also deprecates `Devise::TestHelpers` in favor of `Devise::Test::ControllerHelpers`.
Changelog: https://github.com/plataformatec/devise/blob/v4.2.0/CHANGELOG.md#420---2016-07-01
Working toward #14286, as always.
See merge request !6461
|
| | | | | | | | | |
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This fixes an issue with Rails 5 and brings us up-to-date with the latest Devise release.
This also replaces the deprecated Devise::TestHelpers with Devise::Test::ControllerHelpers.
Changelog: https://github.com/plataformatec/devise/blob/v4.2.0/CHANGELOG.md#420---2016-07-01
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Expose pipeline data in builds API
Exposes pipeline data in builds API, as suggested by #22367.
The fields exposed were 'id', 'status', 'ref', and 'sha'.
Closes #22367
See merge request !6502
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
add pipeline ref, sha, and status to the build API response
add tests of build API (pipeline data)
change API documentation for builds API
log change to builds API in CHANGELOG
CHANGELOG: add reference to pull request and contributor's name
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
'18297-i-would-like-text-to-wrap-when-in-edit-mode-on-web-app' into 'master'"
This reverts merge request !6188
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called
## What does this MR do?
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called, instead return the saved token if one is present.
This was causing a lot of 401s, leading to 403s, as state in #22527
As it turns out, when pushing a lot of LFS objects, the LFS client was calling `git-lfs-authenticate` in the middle of the request again. This caused the `lfs_token` to be regenerated. The problem lies in that the LFS client was not aware of this change, and was still using the old token. This caused all subsequent requests to fail with a 401 error.
Since HTTP Auth is protected by Rack Attack, this 401s where immediately flagged and resulted in the IP of the user being banned.
With this change, GitLab returns the value stored in Redis, if one is present, thus if the LFS client calls `git-lfs-authenticate` again during the request, the auth header will remain unchanged, allowing all subsequent requests to continue without issues.
## What are the relevant issue numbers?
Fixes #22527
cc @SeanPackham @jacobvosmaer-gitlab
See merge request !6551
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Redis connection.
Reset expiry time of token, if token is retrieved again before it expires.
|
