Alias project names to work around Android import issues
Problem to solve
Mirroring or importing Android projects from Gerrit to GitLab can fail because of either reserved project names or namespace conflicts with a group and project of the same name at the same level.
Further details
Android builds use the 'repo' tool and manifest XML files to manage the source base. Updates, version, etc, are often managed with updated manifest files. In this case, Android is provided by a third-party upstream vendor, who has chosen the repository structure and names. Since the commonly used Gerrit allows some options that GitLab does not, it is likely that problems will occur when attempting to import.
Unfortunately, the 'repo' command will attempt to git fetch with the name that is incompatible with GitLab. This is especially problematic if one wants to use a manifest that was tagged and represents an older version of Android. Since changing a tag isn't an option, using an old manifest that had repository naming that isn't compatible with GitLab just won't work.
Reserved Name Case
The manifest may include a reserved name, such as the ones listed here:
https://docs.gitlab.com/ee/user/reserved_names.html
I've personally hit issues with a repository named "update", but other name conflicts could certainly occur.
While it would also solve the problem to just not have reserved names, that is a much bigger feature request and work has already been done to reduce and/or eliminate the restrictions where possible.
Namespace Case
We can encounter a manifest that describes a repository layout like this (where projects end in '.git' and groups/subgroups do not):
foo/build.git
foo/build/sub1.git
foo/build/sub2.git
Here, both build.git and build are in group 'foo' and a namespace conflict on 'build' occurs.
A request to support this case was made in Issue gitlab-ce#35100, but it was determined that it wasn't feasible.
Proposal
Allow a project to have an "alias" that will be mapped onto the actual project name when doing a git push or pull. The alias would not be used for the web page to avoid problems with reserved names.
If a push or pull specified the value of an alias, the alias would be replaced with the actual project name and everything would proceed as if the actual project name had been specified.
An alias would be unique and could not match an existing path.
In the case of a repository called 'update', let us suppose it is in a group foo/bar, so the path would be foo/bar/update. Instead, we will make a project in GitLab called foo/bar/update_proj and then add an alias to the update_proj of "foo/bar/update".
When using the REST API, viewing/exploring groups, use the web interface, it will always be 'foo/bar/update_proj'. However, if a git push or pull request is handled (either over SSH or HTTP), GitLab will look at the requested path ('foo/bar/update') and see that it matches a defined alias, and then continue as if the request had been for foo/bar/update_proj. This means that the manifest and repo utility can continue to use "foo/bar/update".
Similarly, for the namespace conflict, we could do the something similar. If the project 'foo/build.git' is actually 'foo/build_proj.git' and an alias is created fo "foo/build", then the namespace conflict is resolved and "foo/build/sub1.git" and "foo/build/sub2.git" can be created.
So, it would look like:
foo/build_proj.git [alias: foo/build => foo/build_proj]
foo/build/sub1.git
foo/biuld/sub2.git
Alternatively, one could do this:
foo/build.git
foo/build_dir/sub1.git [alias: foo/build/sub1 => foo/build_dir/sub1]
foo/build_dir/sub2.git [alias: foo/build/sub2 => foo/build_dir/sub2]
This could also be used if a project is renamed or moved. An alias could be added for the old name to allow clients to access it as before.
Processing of the aliases would hopefully be straight-forward. On a git request, look up the supplied path in the aliases map. If there is a hit, use the result, otherwise, use the original path.
The unresolved question is how to handle someone creating a project or group that matches an existing alias. One would either have to have an error, or remove the alias.
Reduced scope aliases
The problem described above could also be solved with a slightly more limited version, where a project is only allowed to provide an alias name in its current group or subgroup. This would mean that in the above the example of the alias foo/build/sub2 => foo/build_dir/sub2 would not be allowed, but it might make conflicts and security easier to manage/deal-with.
What does success look like, and how can we measure that?
For success, GitLab could be used with existing Android projects that have the the problems above. (If no way to measure success, link to an issue that will implement a way to measure this)