readthedocs.org

23587291 - GitLab: handle when a repository is moved to another group (#12233)

GitLab: handle when a repository is moved to another group (#12233) So we are clear, GL has some different names for things we know on GH. Organizations: They are called groups, and groups can have subgroups (nesting). In our code we represent each group as a remote organization. Repositories: they are called projects in GitLab. Now, back to the PR... If the repository to sync belonged to a different group (e.g, it was moved or transferred), our code would skip syncing that repository, leaving it in a stale state. Looks like it wasn't clear why we added this check in the first place https://github.com/readthedocs/readthedocs.org/pull/3327/files#r153822778. For GH we always keep repos in sync, so it makes sense to do the same for GL, if GL says the repo was moved to a different group, we should trust that. We were also using the /projects API, and then using the organization check to skip syncing repos that belong to a group instead of the user (we sync projects from all groups the user has access to in a different method, sync_organizations), so I changed it to use the /user/projects endpoint instead. Also, when creating the URL for the group, we were using the path attribute, which is only the last part of the group path, since groups can be nested, this was creating the wrong link. A group from mygroup/subgroup will link to a group named subgroup, which has nothing to do with the actual group, GL has a property with the correct link. We may want to consider using the full_path for the slug of the org, it does contain `/`, but in the model we are accepting any characters for that field, so it shouldn't be a problem, not sure where else we use the slug.