Right now, to hierarchically organize multiple personal projects you either have to create groups or use some sort of hierarchical naming scheme for your user projects. Both approaches are not ideal: With groups, you only have one additional hierarchy level. Using a custom naming scheme, e.g., publications-papers-paper1, still clutters your user projects page and results in very long repository names after cloning (or you have to accept that the top-level directory name on your disk does not match the repository name). Therefore, I propose to add a mechanism to allow the organization of user projects inside "directories" directly in GitLab.
My personal use case is to better organize my work-related projects inside GitLab. At least two large research institutions in Germany that I'm working with (RWTH Aachen University and Forschungszentrum Jülich) have set up GitLab instances that can be used by their members for free. I (and several of my colleagues) use this to store work-related projects, such as scientific publications, research data etc. However, due to the inability to add some sort of hierarchy, I'm starting to lose track of all projects I have and it is also difficult to browse for something that you know/feel exists but not exactly its name.
~"feature proposal"
Proposal
Add ability to hierarchically organize user projects by introducing (sub-)directories for each user. Optionally, extend this feature by adding subdirectories to groups as well.
Links / references
I've found (at least) two proposals that tackle similar issues: gitlab-ce#19860 and gitlab-ce#2772. However, they seem to be limited to either groups or to add projects within projects, which is not exactly what I am looking for.
I have also met with this inconvenience. I resolved it by creating artificial global group username-group and put my supgroups there.
In the issue title I would like to change subgroup -> group. I think that it is groups that we should allow to create under personal namespace and not a subgroups. To create subgroup there should be a parent group. But what will be a parent group for subgroups in personal namespace? Are we treating username as a group?
What I would do is to change Your groups tab in groups dashboard to look similiar to projects dashboard
@vvavrychuk I would treat the personal namespace as a particular kind of group that is public by default and has only one member by definition. Following the same logic, I believe @sloede had in his mind a specific kind of subgroup that can have only one implicit member. Unlike the top-level personal namespace group, such a subgroup could be set to be private or internal as any project created in the scope of the personal namespace.
@gszasz Yes, this is basically what I had in mind. However, when I originally submitted my proposal, I really had only a very limited functionality in mind, i.e., not to treat the personal subgroups as actual groups but rather as some sort of hierarchical naming convention. Having said that, I really like the idea of modeling the personal namespace as a particular group instance and then handling the naming hierarchy via the normal subgroup mechanism. And who knows, maybe this would allow some interesting use cases where you could invite someone else to a personal subgroup for some ad-hoc collaboration on a personal project etc.
This feature (same as gitlab-ce#39485) is one that I was surprised to see doesn't already exist in Gitlab. I would really be happy to see it become a thing so I don't have to use the "create a separate group and ignore your personal path" option.
Is there any work being done on this at the moment?
If not, perhaps can I help with the development of it? It is a core change to an enormous project in a language I'm unfamiliar with so it does sound a bit daunting though. :)
I mentioned this https://gitlab.com/gitlab-org/gitlab-ce/issues/39485#note_98254625 as well, I had the same problem, so I changed my username, and created a group instead of my username. Works quite well, except for some minor weirdnesses sometimes which default to a username.
A similar usecase actually I found interesting was https://gitlab.com/gitlab-org/gitlab-ce/issues/59336 which in the end, results in the same solution. If a group can be a 'special user' or a user is just some extended form of group, both spaces could theoretically simply be merged. This then allows for 'robot' users/access tokens for CI-like tasks.
I'd like to see this feature added; I'm using a normal group as my "personal" group on GitLab.com at the moment, but it has limitations when it comes to billing:
I lose access to additional pipeline minutes I previously purchased under my personal namespace.
I lose access to grandfathered features, so I'd need to upgrade to Silver to keep the same functionality whereas I don't need to under my personal namespace.
In addition to a paid tier seat for myself, I would need to purchase an additional seat just because a third-party has been added to a single repository inside the group; this is inconsistent with the personal namespace, where it doesn't matter how many third-parties have direct access, I only need one paid tier seat for myself.
@markglenfletcher Once we move to the workspace model, once you have a top level namespace, groups and subgroups will basically be the same and will be supported. Added this to &2885 (closed)
@ogolowinski while this is great to here, are there migration thoughts for users (like myself) that have created a group for themselves instead of their persona?
To deal with the fact that I could not have subgroups on my personal space; I created a subgroup for my account instead. While not ideal, it serves me well. With this migration, there might be some things breaking potentially? E.g. I may have to migrate everything around. It would be nice if this would be somehow automatically supported. But since I'm not aware or familiar with the new feature/concept thereof, I'm also not sure how I would be impacted.
I also use a @l3tompouce group in order to use subgroups features I can't use within my personal @letompouce namespace.
About the "migration", I guess it's basically a matter of moving your repos from a namespace to another, then update your local git checkouts' remotes, CICD variables and anything using your group name.
We are developing a new framework for how objects are treated on the backend, giving our customers lots more flexibility with how they structure objects (groups/projects).
Check out this Epic. I'm pretty sure this work (which is already underway) will eventually close this ticket.
Would anyone from the comment section be willing to talk to me about their experience with groups and projects? I'm the new product manager for ~"group::workspace" and am looking to interview users around their current experience to help shape our roadmap. If you are interested, please reach out!
@lohrc I could tell you about my usecase (for this and #15967 (closed), which is related). I like to create projects for writing articles in collaboration. They are short-lived project and limited in scope, and I'd like to keep them under my private namespace, but in a subgroup so they're easier to tell apart from my other more programming-oriented (and hopefully longer-lived) projects. Also some of these articles might include other subprojects, and I'd like to be able archive a whole "tree" of projects (which is where #15967 (closed) comes in).
As it is now, I'm using a https://gitlab.com/articles4 (private group) as a replacement for an articles group in my namespace, and there's a subgroup there that I'd like to archive but I can't.
@lohrc I'd use this feature most on my employer's GitLab Enterprise instance: I work with multiple product teams in my day-to-day; most of those teams have many repositories organized into multiple tiers of subgroups within their namespace. It would be very convenient to be able to make subgroups for each product team (and perhaps subgroups within those if I'm cloning a large number of a single team's repositories) within my personal namespace.
@Jellby@iammattcoleman Would you be available for a 30 min chat to walk me through your use cases in more detail? If so, could I ask you to book some time with me via this link? In case none of the time slots work, feel free to contact me at clohr@gitlab.com
I have the same requirement as @Jellby and I can add the fact to be able to register a runner to a group of project associated to a user.
It's currently a pain to register a runner each time I want to try something under my davinkevin name… and harder to manage because I need to find where my runner is registered when it's shared accros multiple projects.
Another use case:
I want to block creation of top-level groups so users couldn't flood top-level namespace. But I still want users to be able to have subgroups. In this case it is only make sense to create subgroups under user namespace only.