- 01 Aug, 2016 7 commits
-
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
Fixed styling bugs
-
- 29 Jul, 2016 17 commits
-
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
Updated other tests
-
Phil Hughes authored
Switches back to discussion tab when clicking jump to next unresolved button
-
Phil Hughes authored
-
Phil Hughes authored
Reduced some duplicated code with compiling components Fixed bug with resolve button tooltip not updating after resolving discussion
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 28 Jul, 2016 16 commits
-
-
Douwe Maan authored
# Conflicts: # db/schema.rb
-
Douwe Maan authored
Reduce number of queries made for merge_requests/:id/diffs ## What does this MR do? It reduces the number of DB queries made while processing and rendering MR notes. ## Are there points in the code the reviewer needs to double check? N/A ## Why was this MR needed? For `https://staging.gitlab.com/gitlab-org/gitlab-ce/merge_requests/3142/diffs.json`, for each note we make number of DB queries, almost all of them are handled by the AR caching layer, but they seem to add up a few seconds. Testing on staging, calling `merge_requests/3142/diffs.json` was reduced to ~5.5 seconds from ~8 seconds. ## What are the relevant issue numbers? N/A ## Screenshots (if relevant) N/A ## Does this MR meet the acceptance criteria? - [x] [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~~ - [x] 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 !5551
-
Jacob Schatz authored
Replace ci icons with slightly thicker ones ## What does this MR do? Adds updated CI icons ## Why was this MR needed? New CI icons were a tad too thin ## What are the relevant issue numbers? Closes #20089 ## Screenshots (if relevant) ![Screen_Shot_2016-07-26_at_8.59.28_AM](/uploads/35671085829fd64f8a9cf98704661ece/Screen_Shot_2016-07-26_at_8.59.28_AM.png) See merge request !5475
-
Robert Speicher authored
Remove project which can't be pulled while seeding This project can't be pulled from GH when running `SIZE=20 rake dev:setup` [ci skip] See merge request !5559
-
Z.J. van de Weg authored
[ci skip]
-
Stan Hu authored
Add a log message when a project is scheduled for destruction for debugging We have a lot of projects that are in `pending_delete` state. It's not clear whether they were ever scheduled for destruction, or whether Sidekiq just dropped the job due to `MemoryKiller` or some other reason. Also this will provide a record of which user destroys a project. #20365 See merge request !5540
-
Douwe Maan authored
Implement #3243 New Issue by email So we extend Gitlab::Email::Receiver for this new behaviour, however we might want to split it into another class for better testing it. Another issue is that, currently it's using this to parse project identifier: Gitlab::IncomingEmail.key_from_address Which is using: Gitlab.config.incoming_email.address for the receiver name. This is probably `reply` because it's used for replying to a specific issue. We might want to introduce another config for this, or just use `reply` instead of `incoming`. I'll prefer to introduce a new config for this, or just change `reply` to `incoming` because it would make sense for replying to there, too. The email template used in tests were copied and modified from: `emails/valid_reply.eml` which I hope is ok. /cc @DouweM #3243 See merge request !3363
-
Stan Hu authored
-
Rémy Coutable authored
Merge branch '20308-fix-title-that-is-show-in-the-dropdown-toggle-button-on-projects-branches' into 'master' Fix the title of the toggle dropdown button ## What does this MR do? Fix the dropdown-button toggle displaying the correctly title. ## Are there points in the code the reviewer needs to double check? See if the title is displaying correctly and if the code is acceptable. ## Why was this MR needed? When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title. ## What are the relevant issue numbers? Closes #20308. ## Screenshots (if relevant) ![filter-gitlab-ce](/uploads/52838679d134d57c6ff6120260806fda/filter-gitlab-ce.gif) ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - Tests - [x] All builds are passing - [x] 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 !5515
-
Rémy Coutable authored
Reduce instrumentation overhead ## What does this MR do? This MR reduces the overhead of instrumented methods. See the commit message of 905f8d76 for more information. ## Are there points in the code the reviewer needs to double check? Not that I can think of. ## Why was this MR needed? The overhead of method call instrumentation was too great. ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~ - [x] ~~API support added~~ - Tests - [x] Added for this feature/bug - [ ] All builds are passing - [x] 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 !5550
-
Herminio Torres authored
Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value. E.g. When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title. Change the implementation of the `link_to` `filter_branches_path` - Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`. - Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.
-
Yorick Peterse authored
This reduces the overhead of the method instrumentation code primarily by reducing the number of method calls. There are also some other small optimisations such as not casting timing values to Floats (there's no particular need for this), using Symbols for method call metric names, and reducing the number of Hash lookups for instrumented methods. The exact impact depends on the code being executed. For example, for a method that's only called once the difference won't be very noticeable. However, for methods that are called many times the difference can be more significant. For example, the loading time of a large commit (nrclark/dummy_project@81ebdea5df2fb42e59257cb3eaad671a5c53ca36) was reduced from around 19 seconds to around 15 seconds using these changes.
-
Ahmad Sherif authored
-
Phil Hughes authored
-
Rémy Coutable authored
Add commit stats ## What does this MR do? When getting commit by SHA in api it returns commit stats ## Are there points in the code the reviewer needs to double check? Not sure about test I added do we need separate test or we can just shove stats assertion in test above ## Why was this MR needed? So api users/clients can get statistics on single commit ## What are the relevant issue numbers? #20307 ## Screenshots (if relevant) ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [x] API support added - Tests - [x] Added for this feature/bug - [x] All builds are passing - [x] 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 !5517
-
Valery Sizov authored
Added update guide for 8.11 ## What does this MR do? I need to add notes about Elastic on EE side. To not create ugly conflicts in the future and to not duplicate work I created it here first. I followed this guide https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-candidates.md#gitlab-ce See merge request !5545
-