Existing project moved to a sub group loses reference to its repository

Summary

Version 8.16.7 (EE) In our development (playground) environment, we created a group and assigned a parent id to it so it became a subgroup. Transferring a project to it seems to make it think the repository doesn't exist anymore. We noticed the files went to the group's folder, as it's supposed to, but the new "subgroup" is still in the git-data/repositories directory instead of git-data/repositories/parentgroup directory as it's looking for. Moving the files over didn't change the error.

Steps to reproduce

Run the following in gitlab-rails console:

Groups::UpdateService.new(@SUBGROUP, User.find_by(name: 'ADMIN_ACCOUNT'), parent_id: IDNUMBER).execute

SUBGROUP: The group we want as a "sub group", grabbed from Group.find_by() ADMIN_ACCOUNT: The name of the account that would have access to do this IDNUMBER: The id number of the group we want to be the parent

Then go to a project in the parent's group. Go to the settings and do a "transfer project" to the subgroup.

What is the current bug behavior?

Going to the project (After it's been transfered) gives an error message the repository doesn't eixst.

What is the expected correct behavior?

The project's repository should exist.

Relevant logs and/or screenshots

The project's @path_with_namespace gets updated to: "parentgroupname/subgroupname/project" and when we do a .repository.path, we get the directory it's expecting: /var/opt/gitlab/git-data/repositories/parentgroupname/subgroupname/project.git However, when we transfered the project, the repository actually to the following location: /var/opt/gitlab/git-data/repositories/subgroupname/project.git

Results of GitLab environment info

Cannot run sudo commands (do not have permissions for root access on our servers). Can provide if it's 100% necessary to troubleshoot this. omnibus install

Results of GitLab application Check

Cannot run sudo commands (do not have permissions for root access on our servers). Can provide if it's 100% necessary to troubleshoot this. omnibus install

Possible fixes

Not sure where, but perhaps there's a refresh method on the repository object we should be calling after setting the parent_id? Or after we transfer the project? I tried @project.reload but it didn't change anything.

For reference, see https://gitlab.com/gitlab-org/gitlab-ce/issues/2772#note_25817636

mentioned in issue #29527 (closed)

cc @dzaporozhets Are you aware of the above?

mentioned in issue #29725 (closed)

@K73SK Changing the group path should move the repositories in accordance with the change via the Namespace#move_dir after_save callback. If the operation to move the repo on disk failed, theGroups::UpdateService would have indicated such by returning false when you called it from the console. The error would also have been logged to the rails log.

It seems like you are reporting that the project was moved on disk but not from

repos_dir/parent_group_dir/ to repos_dir/parent_group_dir/sub_group_dir

instead it was moved from

repos_dir/parent_group_dir/ to repos_dir/sub_group_dir

Please can you confirm?

added ~65372 settings labels

I'll attempt to reproduce it

@dzaporozhets In 8.17.4 there was the Namespace#full_path_changed? method, but it has since been removed. This considers the parent change, should this be used to determine whether the Namespace#move_dir after_save callback should be invoked?

added subgroups label

Are you aware of the above?

@tauriedavis nope

In 8.17.4 there was the Namespace#full_path_changed? method, but it has since been removed.

@markglenfletcher it was moved there https://gitlab.com/gitlab-org/gitlab-ce/blob/9-0-stable/app/models/concerns/routable.rb#L114-116. Its available for both Group and Project objects.

@markglenfletcher That's correct. The UpdateService did not return false as far as I know... It would have printed that out to standard out I assume? We didn't actually put a check on it. But I would assume it returned OK because the group does show up as a subgroup to the parent as we'd expect/want.

What's most interesting is if we move a project, it does: repos_dir/parent_group_dir/ to repos_dir/sub_group_dir

If we CREATE a new project, it creates it under: repos_dir/parent_group_dir/sub_group_dir as you would hope for.

@K73SK I think instead of trying to make this work via the Rails console, we should open a feature proposal for the moving of a group to another group to be supported properly in the app and API.

I think we need to consider when the parent_id is changing in the condition to invoke the move_dir callback when updating the namespace. It seems that in your case none of the post update actions happened upon updating only the parent_id, move_dir was skipped.

So, I created a new test group, and did the above command to apply it as a subgroup. Then I did the move_dir command right after. From there, I moved a project that was in the parent to the child - it still has the same issue. So what I mean is: ParentGroup / project1 SubGroup

1. Run command above, now have: ParentGroup / SubGroup
2. Run the command: Group.find_by(id: SubGroupID).move_dir
3. (Prints out an empty array)
4. Go to the settings for: ParentGroup / project1
5. Select transfer to "ParentGroup / SubGroup"
6. Go to the project (now "ParentGroup / SubGroup / project1"). Get the error "No Repository"

If this doesn't happen in 9.0, I can inform people that we just need to wait until 9.0 to proceed with subgroups for their projects. I just want to make sure this isn't a bug in GitLab as of now, and it's just something that wasn't finished in the older versions.

The reason I don't think this should be a feature proposal is because it's more of a problem that we can select to transfer a project from a parent group to a subgroup, but then it appears like we lose the repository (when we don't).

For reference on how to fix the "no repository" error: The resolution to get the project back to normal is to set the parent_id in the subgroup to "nil" and then do another "transfer project" in the project settings.

@K73SK This shouldn't be considered a bug if what you are doing, via the rails console, isn't yet a supported feature of the Product. Moving projects to/form subgroups is supported and is working correctly in 9.0. Moving subgroups around(changing the parent ID) isn't supported and warrants a new feature proposal to introduce that functionality.

mentioned in issue #29919 (moved)

Ok, so my guess is the concept of subgroups is only at initial creation of a group. Setting the parent_id to an existing group is "moving" it to a subgroup (which is what you're saying should be a feature request), but in 9.0, you have to create a group AS a subgroup initially. Correct?

Yes a group can be created with a parent ID to establish the parent/child relationship for the subgroup but a parent ID cannot be provided to transfer the group to a different parent.

I don't understand your final statement, there are still top-level groups with no parent that would not be considered a subgroup, in 9.0.

This feature has already been proposed a couple of times since 9.0's release:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/29919

mentioned in issue #30235 (closed)

I've faced this (as far as I understand) problem in V9.0

https://gitlab.com/gitlab-org/gitlab-ce/issues/30235

@terion-name Thanks for confirming that this is not just the old version, but also in >= 9.0

So @markglenfletcher it sounds like it's not from the moving of a group to a subgroup at fault (nor the fact it was before Version 9 came out), but rather the process of moving a project to a subgroup.

Please do not expect rails console to compensate features that does not exist in UI yet. It will likely lead to issues that we cant help you with.

Now related to the issue with moving project to subgroup - it should work well in UI in v9.0 except one case - when parent group was renamed. We fixed this bug by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10414 and it will be part of 9.1.

@dzaporozhets yes, in my ticket #30235 (closed) renaming took place

closed

Thanks for the heads up @dzaporozhets in regards to the parent group being renamed being the issue. We're not using the rails console for subgroups now - it was more of an experiment in our dev environment at the time. Will be looking forward to 9.1 for the fix. :)