Hi all,
we are currently setting up a lecture and exercise series. For that we have created a project template and are trying to fork that into the actual exercises (for sharing a pinned image). Unfortunately forking into the same subgroup under a different name is not working. The template project does not show up in the renkulab project view, and the gitlab fork view does not allow forking into the same subgroup.
edit: after enabling the knowledge graph the template shows up on renkulab.io, but still no dice forking it into the subgroup.
Is there a solution to this?
thanks and cheers
@a_user can you clarify a bit exactly what you are trying to do.
My understanding is that you have a template like this my_subgroup/my_template.
And then you are trying to fork this template to create projects like:
my_subgroup/project1my_subgroup/project2
But if I understand correctly you are having issues forking my_subgroup/my_template to create two new projects with the same name in the same subgroup? So you try to fork my_subgroup/my_template to create my_subgroup/project5 and then you try to do that again, is that correct? If so, this is a limitation of Gitlab where the subgroup or subgroups that precede a project and the project name have to be unique.
But it could be that you are trying to do something completely different. So please let me know.
Unfortunately, there are a few additional limitations in the RenkuLab web interface when dealing with groups and sub-groups.
This means users need to be group owners to create projects there – that includes both new projects and forked projects.
This doesn’t match 1 to 1 with what GitLab allows, so it’s possible users can create a project in GitLab but aren’t allowed to use that namespace in RenkuLab for the same purpose.
Sadly, we don’t have a way to circumvent this limitation: in the past, we had more relaxed constraints and Maintainers (even Developers at some point) could create projects in the group, but that led to hard-to-track problems due to a combination of limitations from the GitLab APIs and how we create Renku projects.
If that is the problem you are facing, I suggest either making the users group owners – if there is enough trust (mind that sub-groups cannot be more permissive than their parent groups) or trying a different solution that doesn’t include GitLab groups.
@tolevski Yes-ish, we try to fork the template to unique names: We have a group/subgroup/template project and want to fork that into multiple group/subgroup/project_[1:13] projects, each name occurring only once. I think you already have access to the course group: ESDS, with 2022 containing last year’s setup.
@lorenzo It turned out to be a case of ownership and permissions: I’m the owner of the main group and only inherited the ownership of the subgroup which does not seem to translate to the renkulab interface properly: I can’t fork into the subgroup. Only the creator of the subgroup itself can fork the template directly into the subgroup itself through the renku interface.
Sadly, GitLab sub-groups permissions are really confusing, but you can make it work.
If I understand correctly, you created a group and another user (let’s name this person “user A”) created a sub-group there. From the GitLab UI, you probably see both users listed as Owner, but in fact your Owner permissions are inherited so they work from the UI but not from the API 
User A needs to invite you as a member explicitly, and then you will be an Owner of the sub-group too and all will work as expected.
Here is a quick video to demonstrate this: we have a user on the Left and one on the Right.
- R creates a subgroup and L is listed as owner (inherited). Still, L cannot see the namespace in the RenkuLab UI.
- R explicitly invites L as an owner. Now L can see the namespace.
Hi @lorenzo
Yes, I’m familiar with all of that. I got motivated to finally make this post after the temlate project did not show up in the renkulab interface at all. It did so only a few minutes after we manually activated the knowledge graph (not sure why that is needed for it to show up all, maybe it syncs the state of projects from gitlab into renku?).
Yeah, the permission model in gitlab seems to be wacky. As an “inherited” owner I can’t invite people as owners to projects or groups created by others either 
We are considering an alternative solution to ditch groups/subgroups but still offer a good solution for whoever needs to keep multiple projects together: that would work for institutions, courses, …
It won’t come soon (still in the incubation phase) but we are aware of the issue and working to have a reasonable solution.
Long story short: GitLab handles projects, but Renku has more abstractions like Datasets, Workflows, … To handle them, we need to process projects’ data somewhere else. The Knowledge Graph is our backend crunching data from GitLab and making metadata available to the platform, protected by users’ permissions.
Theoretically, we could search projects without KG, but the search API from GitLab isn’t very flexible and we can’t have a single search page including the other entities.
We started relying on KG a while ago; the search definitely needs some refining, but it will soon allow us to search for multiple entities (Datasets are already included) and use metadata from the last search to show additional dynamic filtering options.
fair enough, reasonable enough. I just don’t use renku often enough to keep up with the latest interface changes and usually run into a handful of things every time I come back to setup things 