- 26 Aug, 2018 1 commit
-
-
Gabriel Mazetto authored
-
- 16 Aug, 2018 1 commit
-
-
Valery Sizov authored
-
- 23 Jul, 2018 1 commit
-
-
blackst0ne authored
`perform_enqueued_jobs` is a Sidekiq method. Using this method violates the Dependency inversion principle[0]. This commit replaces `perform_enqueued_jobs` with ActiveJob's abstract method `perform_enqueued_jobs` in specs. [0]: https://en.wikipedia.org/wiki/Dependency_inversion_principle
-
- 25 Apr, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
Direct disk access is done through Gitaly now, so the legacy path was deprecated. This path was used in Gitlab::Shell however. This required the refactoring in this commit. Added is the removal of direct path access on the project model, as that lookup wasn't needed anymore is most cases. Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
-
- 07 Feb, 2018 1 commit
-
-
Nick Thomas authored
-
- 22 Aug, 2017 1 commit
-
-
Gabriel Mazetto authored
-
- 02 Aug, 2017 1 commit
-
-
Robert Speicher authored
-
- 28 Jul, 2017 1 commit
-
-
Z.J. van de Weg authored
When destroying a group, now an API call is made to the Mattermost server to request the deletion of the project. Actual team deletion on the Mattermost side happens async, so the runtime shouldn't increase by more than a second.
-
- 27 Jul, 2017 2 commits
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 29 Jun, 2017 1 commit
-
-
Stan Hu authored
Group#destroy would actually hard-delete all associated projects even though the acts_as_paranoia gem is used, preventing Projects::DestroyService from doing any work. We first noticed this while trying to log all projects deletion to the Geo log.
-
- 19 Apr, 2017 1 commit
-
-
James Lopez authored
-
- 28 Mar, 2017 1 commit
-
-
Robert Speicher authored
-
- 27 Feb, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 16 Feb, 2017 1 commit
-
-
Stan Hu authored
There are two problems in the current implementation: 1. If a project is marked for deletion via the `pending_delete` flag and then the namespace was quickly deleted, it's possible that the namespace skips over that project and leaves that project in an orphaned state. 2. Before namespace deletion, the namespace attempts to clean up all the relevant storage paths. However, if all projects have been removed synchronously, then the namespace will not be able to clean anything. To prevent this, we should load the paths to be deleted before actually destroying projects. The specs were missing this second case due to a permission issue that caused project removal never to happen.
-
- 08 Feb, 2017 1 commit
-
-
dixpac authored
* Changed name of delete_user_service and worker to destroy * Move and change delete_group_service to Groups::DestroyService * Rename Notes::DeleteService to Notes::DestroyService
-
- 18 Nov, 2016 1 commit
-
-
Timothy Andrew authored
- Use multiple threads / database connections to: 1. Escape the transaction the spec seems to be running in (`config.use_transactional_fixtures` is off, but `ActiveRecord::Base.connection.open_transactions` is not empty at the beginning of the spec. 2. Simulate a Sidekiq worker performing the hard delete outside of the soft-delete transaction. - The spec is a little clunky, but it was the smallest thing I could get working - and even this took a couple of hours. Let me know if you have any suggestions to improve it!
-
- 11 Aug, 2016 1 commit
-
-
Stan Hu authored
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 to run execute directly on Projects::DestroyService. Closes #17893
-
- 30 Jun, 2016 1 commit
-
-
Alejandro Rodríguez authored
-
- 09 Dec, 2015 1 commit
-
-
Douwe Maan authored
-
- 13 Jun, 2015 2 commits
-
-
Robert Speicher authored
-
Robert Speicher authored
-
- 03 Jun, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-