GitLab Migration - projects with the same name but different path can clash and fail to be created during the migration
Context
For historical reasons, projects within a namespace need to have unique paths and names, as well as subgroups within a namespace need to have unique paths and names. However, a subgroup and project with the same name within a namespace are allowed.
For example, suppose the following namespace exists:
|-- name: "GitLab", path: "gitlab", type: "group"
| |-- name: "Subgroup", path: "subgroup", type: "group"
│ |-- name: "Project", path: "project", type: "project"
If we want to add more subgroups and projects to the GitLab namespace, we need to make sure the "path" and "name" are unique for the respective type.
-
name: "Subgroup", path: "subgroup_2", type: "group"
- Group name needs to be unique -
name: "Subgroup 2", path: "subgroup", type: "group"
- Group path needs to be unique -
name: "Subgroup 2", path: "project", type: "group"
- Group path needs to be unique (Conflicts with the existing project path) -
name: "Project", path: "project_2", type: "project"
- Project name needs to be unique -
name: "Project 2", path: "project", type: "project"
- Project path needs to be unique -
name: "Project 2", path: "subgroup", type: "project"
- Project path needs to be unique (Conflicts with the subgroup path)
name: "Subgroup 2", path: "subgroup_2", type: "group"
name: "Project 2", path: "project_2", type: "project"
-
name: "Project", path: "subgroup_2", type: "group"
- Note that the group name is the same as the existing project -
name: "Subgroup", path: "project_2", type: "project"
- Note that the project name is the same as the existing group
Knowing these restrictions is important because we need to ensure the migration won't fail when attempting to create the records.
GitLab Migration
In the file base import, the path
and the name
of the new group or project are requested in the UI and validated before the import process starts.
In GitLab Migration UI and API, only the path is requested (Note: a few issues were created to make the UI and API to use path
. Before, the UI was using path
and the API name
). In terms of validations, the path uniqueness is only validated in the frontend. So migrations created via API can fail later in the process if the provided path isn't unique (Note 2: created this issue to fix the validation in the backed)
Because GitLab Migration only requests the user to provide the path, on !91512 (merged), we updated GitLab Migration to handle duplicated group names by using the original group and append an incremental prefix in case of duplicated names. However, we didn't apply the logic for projects.
Problem
Right now, this isn't a problem because GitLab Migration doesn't support granular project migrations, so migrated projects will always be created on a namespace that doesn't have children, which means the project names and paths won't conflict.
However, as soon as we enable granular project migrations, projects are going to be migrated to non-empty namespaces, and possibly a name conflict can happen and cause the migration to fail.
Solution breakdown
- Update BulkImports::Projects::Graphql::GetProjectQuery to fetch the project name from the API
- Update BulkImports::Projects::Transformers::ProjectAttributesTransformer to create incremental project names
The first point here was addressed with !115780 (merged). The second point here has been addressed in !113417 (merged).