Centralize logic for path updates with project with packages
The following discussion from !18515 (merged) should be addressed:
-
@10io started a discussion: (+2 comments) I'm not happy with the implementation of these checks. Basically, it's spread over several service objects. Moreover, we have a single check for npm packages but in future when adding more package types other name conventions will need to be enforced and so the checks will grow.
I'd like to keep things centralised. Perhaps using a new service object with the purpose of validating each action (group update, group transfer, project transfer). The new service would encapsulate all the logic for all the package types (example: for project with npm packages, root namespace can't be modified). This way the update or transfer service objects has a single call to this new "validation" service object and the different naming conventions checks are not spread among different services.
What do you think? It doesn't sound bad but it looks like this refactoring into a new service object should be done in a follow-up MR and not on this one.
Problem
When a project gets a path update by:
- group updating its path
- group transfer
- project transfer
- username update
a validation should be run to ensure that naming conventions for packages are properly followed (see those for NPM packages. This is to ensure that package managers will still work with the GitLab repositories.
Once !18515 (merged) this validation will be spread over several services:
- (group) UpdateService
- (group) TransferService
- (project) TransferService
Proposal
Since packages support is expected to add several other package types, it would be wise to centralize this validation into a single service object so that adding new package types is easier.
Caution with how each services flag an object as invalid. Sometimes it's by raising a custom Error, sometimes it's by adding an error to the given model.errors structure.