- 15 Aug, 2016 22 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Yorick Peterse authored
Try to get back todo's cache or at least avoid hitting the database See merge request !5789
-
Yorick Peterse authored
Speed up todos queries by limiting the projects set we join with See merge request !5791
-
Ahmad Sherif authored
Follow-up 1003454c
-
Ahmad Sherif authored
Follow-up on 1003454c
-
Ahmad Sherif authored
-
Ahmad Sherif authored
Closes #20828
-
Yorick Peterse authored
Change the order of the access rules to check simpler first, and add specs See merge request !5799
-
Jeroen van Baarsen authored
Ability to restrict branches for pivotal tracker integration ## What does this MR do? It allows to specify branches which you want to track for pivotal tracker integration. ## Why was this MR needed? Typical use case: send commits to PivotalTracker and finish the story only when the feature branch is merged into master. See merge request !5752
-
Yorick Peterse authored
Fix a memory leak caused by Banzai::Filter::SanitizationFilter See merge request !5808
-
Egor Lynko authored
-
- 14 Aug, 2016 1 commit
-
-
Ahmad Sherif authored
In Banzai::Filter::SanitizationFilter#customize_whitelist, we append three lambdas that has reference to the SanitizationFilter instance, which in turn (potentially) has a reference to the following chain: context hash -> Project instance -> Repository instance -> lookup hash -> various Rugged instances -> various mmap-ed git pack files. All of the above is not garbage collected because the array we append the lambdas to is the constant HTML::Pipeline::SanitizationFilter::WHITELIST.
-
- 12 Aug, 2016 17 commits
-
-
Douwe Maan authored
Don't show new MR URL after push when it doesn't make sense See merge request !5786
-
Rémy Coutable authored
Add archived badge to project listing ## What does this MR do? Add an `archived` badge to the user project list, if the project is archived. ## Are there points in the code the reviewer needs to double check? No. ## Why was this MR needed? Customer noted in https://gitlab.zendesk.com/agent/tickets/33787 that there is no distinction for archived projects in the project dashboard/explore projects page. There is an archived badge on the admin projects page, though. ## What are the relevant issue numbers? ## Screenshots (if relevant) Existing admin projects page: ![Screen_Shot_2016-08-12_at_3.54.37_PM](/uploads/d6ba44c2d3be1f78372792b5ac406672/Screen_Shot_2016-08-12_at_3.54.37_PM.png) New project list with archived badge: ![Screen_Shot_2016-08-12_at_3.54.21_PM](/uploads/3fa8bb9fe7588575aace0761984929a7/Screen_Shot_2016-08-12_at_3.54.21_PM.png) See merge request !5798
-
Douwe Maan authored
-
Alejandro Rodríguez authored
-
Drew Blessing authored
-
Robert Speicher authored
Fix bug where destroying a namespace would not always destroy projects There is a race condition in DestroyGroupService now that projects are deleted asynchronously: 1. User attempts to delete group 2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project 3. DestroyGroupService destroys the Group, leaving all its projects without a namespace 4. Projects::DestroyService runs later but the can?(current_user, :remove_project) is `false` because the user no longer has permission to destroy projects with no namespace. 5. This leaves the project in pending_delete state with no namespace/group. Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since `container_registry_path_with_namespace` is the wrong value. The fix is to destroy the group asynchronously and run `execute` directly on Projects::DestroyService. Closes #17893 See merge request !4341
-
Douwe Maan authored
Update ruby 2.3.1 We where using 2.3.0, now 2.3.1 cc @connorshea See merge request !5790
-
Jacob Schatz authored
Resolve "Format branch, tag, and commit in environment list" ## What does this MR do? Updates Environments page rows to match the new pipeline updates ## Are there points in the code the reviewer needs to double check? I removed `private` from `avatars_helper.rb` so I could use `user_avatar`. ## What are the relevant issue numbers? Closes #20059 ## Screenshots (if relevant) ![Screen_Shot_2016-08-08_at_11.44.36_AM](/uploads/62fbb475a7d9cc613fe5ba1715229553/Screen_Shot_2016-08-08_at_11.44.36_AM.png) ![Screen_Shot_2016-08-08_at_11.44.41_AM](/uploads/ce1bd3ab62c0bc8091e9b6f85012ed36/Screen_Shot_2016-08-08_at_11.44.41_AM.png) See merge request !5687
-
Paco Guzman authored
We’re being kept up to date the counter data but we’re not using it. The only thing which is not real if is the number of projects that the user read changes the number of todos can be stale for some time. The counters will be sync just after the user receives a new todo or mark any as done
-
Paco Guzman authored
-
Rémy Coutable authored
Instrument Project.visible_to_user ## What does this MR do? This MR instruments `Project.visible_to_user` ## Are there points in the code the reviewer needs to double check? No. ## Why was this MR needed? The method in question was not instrumented due to being a Rails scope. ## What are the relevant issue numbers? #12425 ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - Tests - [ ] All builds are passing - [x] 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) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) See merge request !5793
-
Rémy Coutable authored
Improve pipeline processing ## What does this MR do? This works on top of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5295 trying to solve some edge cases introduced by that Merge Request. The fix switches to a state machine which is already a part of `Ci::Pipeline` and uses events with conditional transitions to switch between pipeline states. This is approach is much more bullet proof and much easier to understand than a previous one where we were calling a `reload_status!` which manually updated `status`. Previous approach become confusing and prone to number of errors. ## Why was this MR needed? This improves changes introduced by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5295 ## What are the relevant issue numbers? None, yet. ## Screenshots (if relevant) Not needed. ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added (not needed since changelog for https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5295 is already introduced) - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [x] API support added (not needed) - Tests - [x] Added for this feature/bug (most of tests do cover the triggering of Pipeline) - [ ] 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) - [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) See merge request !5782
-
Yorick Peterse authored
Because this method is a Rails scope we have to instrument it manually as regular the instrumentation methods only instrument methods defined directly on a Class or Module.
-
Kamil Trzcinski authored
-
Z.J. van de Weg authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-