Hi Everyone,
I have trouble with the following:
Our local GitLab CE is quite messed up (from group/project structure). Someone created a group and put a project there. Someone else should have put his project to the same group but instead created a different group (with similar) name, or even created it in his own namespace granting access to other members. We seriously need to reorganize it because it it quite impossible to find anything…
Unfortunately, the mess was building up for quite some time and there are links in documentation, build scripts, issue tracker, that point to the current repo paths. I tested the transfer/rename functionality and the redirect from the old path to the new one works really nice. The issue here is, that sooner or later someone will create a project that reclaims the old path (for example sandbox/test1 or event user.namespace/test that at the moment contain production code 
).
What are our options to prevent this?
The “easiest” thing would be to prohibit creation of the same project paths that exist at the moment. Unfortunately I haven’t found a way to achieve this.
Mirroring to new gitlab instance seems too dangerous (it would have to be both puss and pull mirroring) and kind of overkill.
Disallowing personal projects and instead creating a sandboxForEveryone group (while restricting root group creation to several admins) feels too restrictive…
Any other ideas or tips?
Thanks…
Seems I have found a “hack” for the preferred solution (solution number one):
The “easiest” thing would be to prohibit creation of the same project paths that exist at the moment. Unfortunately I haven’t found a way to achieve this.
Admin area -> Settings -> Hashed repository storage paths has to be turned off from the beginning of GitLab usage (luckily this is true for our instance)- On the server the gitlab is running you find where your gitlab git repositories are stored (
/var/opt/gitlab/git-data/repositories or similar)
- You run a search for .git directories (.wiki.git directories can be ommited)
- At this point you have to “mark” your directory structure that should resemble the groups/subgroups/projects in your gitlab. For example by copying it somewhere else. Mark that *.git directory contents are not needed. You don’t have to copy them. All you need is correct directory name in a correct group/subgroup (or user namespace) path.
- Now comes the part where you do all your restructuring. You create the new groups. Transfer the projects into them, etc. Thank’s to gitlab all the links from the original paths are redirected to new paths. This will also change your
git-data/repositories structure to match new groups…
- And here comes the “hack” itself. To prevent the reclaiming of the old paths with new projects you have to prevent creation of new projects with same name. To achieve this, you have to copy the “marked gitlab repository directory structure” back into
git-data/repositories. (Be careful not to overwrite the repos you haven’t moved.)
This results into state, where, in the gitlab UI you won’t see the original path of repos. The redirects for original paths will still work (and redirect to the new path). But… If you try to create a new project that should reclaim the link, the GUI will give you an error stating that it is not possible to create the project (in older gitlab version I got “Repo already exists” in the newer “Failed to create repository”).
As to why Hashed repository storage paths has to be turned off… Once the group/project is created with Hashed repository storage paths on, its path is immutable. No matter where you transfer the project, its path remains the same. Project with same name (in the original path) will receive a new hash path. Therefore you don’t have anything to trick gitlab into thinking that the path is already taken…
Side note: You might make this viable even with Hashed repository storage paths turned on. After turning them off, if you transfer projects/groups the new directory structure pops out on the disk. Therefore by transferring/renaming you might be able to recreate the needed directory structure and reproduce the steps.