summaryrefslogtreecommitdiff
path: root/app/services/projects/after_rename_service.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42GitLab Bot2022-07-201-0/+13
|
* Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42GitLab Bot2022-06-201-14/+0
|
* Add latest changes from gitlab-org/gitlab@14-4-stable-eev14.4.0-rc42GitLab Bot2021-10-201-3/+5
|
* Add latest changes from gitlab-org/gitlab@14-2-stable-eev14.2.0-rc42GitLab Bot2021-08-191-1/+1
|
* Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42GitLab Bot2021-05-191-5/+3
|
* Add latest changes from gitlab-org/gitlab@13-4-stable-eeGitLab Bot2020-09-191-5/+14
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-131-0/+2
|
* Move MigrationService to HashedStorage moduleGabriel Mazetto2019-01-251-1/+1
| | | | | This is part of the refactor to include a RollbackService into HashedStorage module
* Refactored AfterRenameService to reduce couplingGabriel Mazetto2019-01-221-12/+17
| | | | | | | | | | | We still rely on the Dirty API for project rename (before/after) values, but we don't access the dirty api from the service class anymore. The previous value is now part of the initialization, which makes it easier to test and the behavior is clearer. The same was done with the `rename_repo` on the Storage classes, we now provide before and after values as part of the method signature.
* Fixed legacy storage renaming codeGabriel Mazetto2019-01-211-1/+1
| | | | | | | | | | | | | | | During a previous refactor on project model, code related to the hashed storage was extracted into AfterRenameService, see 4b9c17f196bab6075563f62d01f9db65c1a0515c. The "path_before" was changed from using `previous_changes['path']` to `path_was`. They are not equivalent. `path_was` exists reliably only *before* persisting to the database. After database persistence is confirmed, the value is moved to `previous_changes[:attribute_name]`. Because the repository/attachments rename or storage upgrade happens after it was persisted to the database, we were in fact not informing the right parameters (and therefore not doing what it was supposed to).
* Update storage location after a project has been renamedDouglas Barbosa Alexandre2018-12-211-0/+1
|
* Move Project#rename_repo to a service classrefactor-project-rename-repoYorick Peterse2018-10-221-0/+135
This moves the logic of Project#rename_repo and all methods _only_ used by this method into a new service class: Projects::AfterRenameService. By moving this code into a separate service class we can more easily refactor it, and we also get rid of some RuboCop "disable" statements automatically. During the refactoring of this code, I removed most of the explicit logging using Gitlab::AppLogger. The data that was logged would not be useful when debugging renaming issues, as it does not add any value on top of data provided by users. I also removed a variety of comments that either mentioned something the code does in literal form, or contained various grammatical errors. Instead we now resort to more clearly named methods, removing the need for code comments. This method was chosen based on analysis in https://gitlab.com/gitlab-org/release/framework/issues/28. In this issue we determined this method has seen a total of 293 lines being changed in it. We also noticed that RuboCop determined the ABC size (https://www.softwarerenovation.com/ABCMetric.pdf) was too great.