Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
Fix build sidebar build details padding
## What does this MR do?
Removes a `.block-first` overriding declaration that was added to fix the coverage padding and moved the padding that fixes the coverage block to a `.block.coverage` declaration.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
The build sidebar build details had too much padding as seen in #22529.
## Screenshots (if relevant)
![Screen_Shot_2016-09-24_at_19.38.40](/uploads/2c11a71f3022909fe8a5d1e983445667/Screen_Shot_2016-09-24_at_19.38.40.png)
![Screen_Shot_2016-09-24_at_19.39.06](/uploads/482af29f4bb7e284469466da59901087/Screen_Shot_2016-09-24_at_19.39.06.png)
## 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 #22529
See merge request !6506
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert to use Mounter method to check existence
## What does this MR do?
Revert a change on gitlab-ce that we never get into gitlab-ee due to spec failures and a lack of a proper solution. So we want to keep both repos in the same codebase about this.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## 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 #22768
See merge request !6590
|
|
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>
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
See: https://gitlab.com/gitlab-org/gitlab-ce/commit/6280fd3777920670ee42111fddf29576cbf85988#note_14766241
We wanted to avoid accesses to the file system, because it seems reasonable that if the mounter column has some content it’s because there are an associate file. This is an speed boost when you access to a bunch of build instances to show their information.
The problem is that solution doesn’t work if you uses that method to detect the thing and you’re changing the uploaded file on instances that had that column empty. Until you don’t persist the instance the database column will be empty so we can have false negatives
|
|
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.
|
|
moved the padding to a new coverage block declaration
Review changes
|
|
|
|
|
|
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
|
|
|
|
|
|
Remove instances of HTML5 input type="color" due to inconsistent browser support
## What does this MR do?
`<input type="color" />` renders differently across browsers. Reverting to `type="text"` where necessary.
## Screenshots (if relevant)
Safari (top) vs Chrome (bottom)
![Screen_Shot_2016-09-28_at_11.53.02_AM](/uploads/f967ed988320cbd2e4357cdfcfe7a813/Screen_Shot_2016-09-28_at_11.53.02_AM.png)
See merge request !6576
|
|
|
|
button
|
|
|
|
See https://gitlab.com/gitlab-org/gitlab-ce/issues/22759
|
|
'18297-i-would-like-text-to-wrap-when-in-edit-mode-on-web-app' into 'master'"
This reverts merge request !6188
|
|
Add Pipelines for Commit
## What does this MR do?
This adds a Pipelines for Commit.
I used existing view that we use to show pipelines. However, this is completely ugly with a lot of redundancy.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
![Screen_Shot_2016-09-13_at_13.43.38](/uploads/0ac6e7d4825e32dba7ff7ab051da837c/Screen_Shot_2016-09-13_at_13.43.38.png)
## 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?
Resolves https://gitlab.com/gitlab-org/gitlab-ce/issues/18937
See merge request !6322
|
|
'22592-can-set-due-date-through-slash-commands-even-though-i-m-not-authorized-to' into 'master'
Fix permission for setting an issue's due date
## What does this MR do?
This merge request ensure the current user can `:admin_issue` in order to change the issue's `due_date`, in `BaseIssuableService` and in `SlashCommands::InterpretService`.
Closes #22592
## Are there points in the code the reviewer needs to double check?
No.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [x] 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 !6539
|
|
|
|
|
|
Added tests
Added awesomeeeeee icons
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
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>
|