Subgroups in Gitea #1872

Open ulm0 opened 7 years ago

Feature proposal

GitLab 9.0 now allows to create subgroups for groups/organizations, It would be great if we could do the same in Gitea.

Subgroups Docs: https://docs.gitlab.com/ce/user/group/subgroups/

Does Teams provide some or all of this functionality? What is missing from Teams?

Teams would not provide "endless" nested groups 🙁

In any case, this would require a large rewrite of how we're handling Organizations today (GitLab put a lot of time into Subgroups...) and would not be backwards compatible (hence why Subgroups in GitLab was introduced in a Major release so breaking changes was allowed 🙂 )

And to better answer @razzintown, Teams can't have repositories.

Let me know if my understanding is correct:

Teams can't have repositories.

Repositories may be assigned to one or more teams.

Repositories may be set to private to prevent other teams from seeing them.

Teams would not provide "endless" nested groups :slightly_frowning_face:

Team names may contain a dash to give the appearance of nested groups, i.e. "company-department", "company-department-managers", etc.

Since multiple teams may share a private repo, is there any other functionality missing?

Sub-groups are not only about permissions, but structure as well. Say you have an Orga with a total of 300 repos over 30 teams, there's no way to structure that w/o proper "folders" (sub-groups).

So in the end you end up with orga/team30/repo10 instead of orga/repo300

In any case, this would break a lot of existing stuff and be a major overhaul so I'm setting this for 2.0 for now

This would automatically give us the pastebin/gist feature #693 as well, or any related idea, since some nested names could be reserved for those features like giteaUser/gist or giteaUser/pastebin just off the top of my head, or with a dot prefix if that's legal with git, not sure. It would also allow users to create new repos progamatically with permissions already set by the parent 'space'.

It could also eventually allow federation since it basically boils down to automagic merging, and using mirrors nested in reserved namespace would allow for manual conflict resolution as fallback without polluting the root namespace with lots of mirrors.

We org our git projects into groups of bounded contexts. Where the git repo is, informs the purpose, scope, and communication channels, as well as the authorization to the project. subgorups can be valuable.

Is there any estimable timeline when this could potentially be implemented? This would be super useful.

@Th3Whit3Wolf No people are working on this.

Still no update?

dont see any

I use Gitea for myself and Gitlab for team work. In Gitlab we have subgroups containing a lot of repos. That's what's keeping us from migrating. This possibility in Gitea would be really great. Is this feature is planned?

It is planed but nobody does work on this currently

Ok thanks for the confirmation

Currently this feature is already available in Github

would also love this feature. Our team is migrating from GitLab and this is a feature we sorely miss

I'm planing to work on virtual subgroup functionality that would not affect urls so repository names would still need to be unique but it would allow grouping repos in subgroups

I dig how GitLab groups can be used for access control - would the virtual subgroups be similarly used? ... and I like the namespace. For example, I'd like parent Gitea groups for bounded contexts. Each context could have subgroups based on convention as schemata or api or handbook, etc. Having to have unique names would end up with virtual-groupname/groupname-schemata or the like.

GitLab has some troubles sorting out GitLab Pages' domains with subgroups. What makes subgroups difficult with Gitea?

I agree, but I think virtual subgroups without namespaced paths is a good and easy starting point. I support that for sure but would also like to see it go further.

With or without URL path, the important thing is to have some repositories into subgroups.

I agree the url path is not most important and the GitLab implementation is still a bit janky. There is the access control issue but as some have stated, there is also the UX concerns of organizing repos by groups and subgroups.

ABAC systems and advanced content systems both work off of taxonomies. Maybe adding a parent attributes is how @lafriks plans on implementing virtual groups. We could have both access control policies and visual organization based on attributes. Maybe an attribute approach would this would better facilitate organization to structure as we want our software (network of contexts) rather than based on a tree like the HR org chart (conway's law).

Would you like any help with this feature @lafriks?

Another interesting aspect of the way Gitlab subgroups work is that you can use relative git submodules (to access the repositories with both ssh and https and allow exporting offline builds):

https://docs.gitlab.com/ee/ci/git_submodules.html#configure-the-gitmodules-file

Is there a place available to fund this issue?

You can visit https://www.bountysource.com/teams/gitea

Has anyone an idea what happened to this feature request?

Even if it was added to the 1.15 roadmap #14477, it wasn't implemented. I also didnt found anything regarding a more fine grained orga/team handling in 1.16 #16429.

We would love to see this feature in gitea.

It's on my individual backlog but have been quite busy lately so it will be done when it's done :D

I was reorganizing my repositories to match my local folder organization and was bugged not to find the create subgroup button (gitlab reflex from my job) :D

I was reorganizing my repositories to match my local folder organization

@seboss666 Genuinely interested in knowing how you "reorganize" repositories...? Do you mean like with APIs? Or do your repos just have code and no issues/PRs/Wiki/etc, so you can just clone and re-upload under a different name?

I was reorganizing my repositories to match my local folder organization

@seboss666 Genuinely interested in knowing how you "reorganize" repositories...? Do you mean like with APIs? Or do your repos just have code and no issues/PRs/Wiki/etc, so you can just clone and re-upload under a different name?

I've split a big bloated repo into multiple ones, and was hoping to "group" them. For now, my repositories are almost all just codes, any "wiki" goes to a dedicated wiki elswhere, and for the rare issues I would like to keep, the "original" repository is still there, just with less far code.

In our company we have such kind of repository organization: org/project/repos Where org correspond more or less to department/metier which could handle lots of projects and for each projects, we are splitting repos according to lifecycle of data handled into as we are doing development in a very constrained process (eg we cannot handle test suite and source code into the same repo) Another usage of nested organization which could help us is for consequent projects like a complete suite of projects with hundreds of developers. In that case, we have such organization: program/project/repos Where program is the suite, then projects hosted by the suite and repos with same constraints as above Having nested organizations feature in gitea would definitively be an enabler for us If my understanding is correct, it looks like that feature could help to close the gap

Expect this feature

Currently this feature is already available in Github @cwchristerw at https://github.com/go-gitea/gitea/issues/1872#issuecomment-674498347

where??

the organizations hosted on github which release multiple applications for different different platforms are such a scattered mess (no offence). examples:

(will post later)

https://telegram.org/apps#source-code **WithOUT subgroups** / (github-root) ├── tdlib │ ├── [td] │ ... ├── TelegramMessenger │ ├── [Telegram-iOS] │ ... ├── telegramdesktop │ ├── [tdesktop] │ ... ├── [Telegram] ├── [TelegramSwift] ├── [tweb] ├── [telegram-tt] ├── [webogram] ├── [telegram-react] ├── [telegram-wp] ... **With subgroups** / (github-root) └── telegram ├── tdlib │ ├── [td] │ ... ├── android │ ├── [Telegram] │ ... ├── iOS │ ├── [Telegram-iOS] │ ... ├── desktop │ ├── [tdesktop] │ ... ├── mac │ ├── [TelegramSwift] │ ... ├── web │ ├── [tweb] │ ├── [telegram-tt] │ ├── [webogram] │ └── [telegram-react] └── [telegram-wp] [td]: https://github.com/tdlib/td [Telegram-iOS]: https://github.com/TelegramMessenger/Telegram-iOS [tdesktop]: https://github.com/telegramdesktop/tdesktop [telegram]: https://github.com/DrKLO/Telegram [TelegramSwift]: https://github.com/overtake/TelegramSwift [tweb]: https://github.com/morethanwords/tweb [telegram-tt]: https://github.com/Ajaxy/telegram-tt [webogram]: https://github.com/zhukov/webogram [telegram-react]: https://github.com/evgeny-nadymov/telegram-react [telegram-wp]: https://github.com/evgeny-nadymov/telegram-wp

this feature would be great to have in gitea!

Just curious how things are with this FR any updates?

Thank you for the support!

Regards, Dave

I've just finished a gitea trial for our company which failed on this issue. I believe gitea is one of the best git hosting solution, but without this capability it is just not enterprise ready. If you have dozens of git repositories and different user groups than it is a nightmare to manage all on the same level. For my boss: that was a no go. Now I am stuck with gitlab, what is an ugly monster compared with gitea (at least from the administration point of view).

ps: This issue is currently the 5th most liked (I assume that meant 5th most requested) amongst 1800+ (!) open issues...

I've just finished a gitea trial for our company which failed on this issue. I believe gitea is one of the best git hosting solution, but without this capability it is just not enterprise ready. If you have dozens of git repositories and different user groups than it is a nightmare to manage all on the same level. For my boss: that was a no go. Now I am stuck with gitlab, what is an ugly monster compared with gitea (at least from the administration point of view).

ps: This issue is currently the 5th most liked (I assume that meant 5th most requested) amongst 1800+ (!) open issues...

Perhaps you could convince your employer to contribute some manpower to Hacktoberfest and help implement it…

@atommaki Im one to have liked subgroups but this position of subgroups being deal break seams both anomalous and hyperbole, ie, not productive. GitHub is not suitable for your company either? Subgroups being the deal breaker seems anomalous.

GitHub has over 200 million repos, used by 73 million developers with 32 million visits per month. The lack of subgroups has not impeded use and adoption. I couldnt find an org count but have worked at places with over 1000 repos and regularly see orgs with dozens and they have not left for GitLab's subgroups.

As VP of Eng that finally go my way and purchased GitLab, I was pissed to run into bugs for Enterprise features that were over 2 years old and waiting for community contribs. I ended up getting the contact cancel, money back, and moved to GitHub where thinks actually work. GitLab's open core model is a lie, the worse of both worlds where the community is exploited and the company focuses on royalty extraction. The fact that GitLab has subgroups and GitHub does not is negligible.

If dozens of repos with various user groups is too much to admin, I dont understand how managing GitLab with subgroups makes that big of difference. Yes a subgroup can be configured to inherit some settings from the parent group but its still massive amount of point and click admin.

You can use terraform/pulumi, a github app, or even crossplane to manage your github and gitlab config. Perhaps the administration experience and functionality is where Gitea should focus? Build-in a configure all the settings by in repo config file?

Im also a fan of shared repos for each service boundary or bounded context so a team typically only deals with one repo. You end up with some monorepo cicd config addressing separate workspaces but your business might only have 10 bounded contexts and dozens is unlikely. I dont see massive value difference in subgroups vs a shared repo, at least not enough to put up with GitLab's business model.

@mrexodia

Perhaps you could convince your employer to contribute some manpower to Hacktoberfest and help implement it…

My company goes with gitlab now and not interested in another migration, so they motivation is low. However I am happy to help. Write me a pm and let's have a call...

@tomdavidson Github has subgroups, but it works bit differently, as soon as you register you have your "domain" of repositories and access management. But anyway, regardless how github works, a tree based structure is usually very natural for a company, it helps not only with the permissions, but gives you a good overview of what repositories you have and it likely mirroring some way the structure of the organization. And as it quite obvious from this thread I am not the only one thinking like this. This feature is missed by many.

wow lol. this argument is just so awesome. i really really like this.

P.S: same can be said for the lack of FOSS model of github. so, why bother with creating yet another Forge site. the point should be improving upon, and not just copy pasting some other popular existing service.

lack of sub-groups is a deal breaker for those who have used the subgroups even once, the same way non-FOSS becomes a deal breaker for people who start to enjoy FOSS even once.

Tom Davidson wrote:

@atommaki https://github.com/atommaki Subgroups being the deal breaker seems anomalous.

GitHub has over 200 million repos, used by 73 million developers with 32 million visits per month. The lack of subgroups has not impeded use and adoption.

Let's stay to the topic, this is not place for discussion. If you have nothing to add that would contribute to implementing this feature in Gitea, just add reaction to issue. Otherwise if you want to see this issue fixed you will have to wait, implement yourself or pay someone to implement this for you.

1.21 Will it be implemented? Very good. Multifunctional

1.21 Will it be implemented? Very good. Multifunctional

Why do you think that? Nobody are working on this.

To clarify @lunny's words: Gitea is (almost solely) developed by volunteers in their free time. If you want a (large) feature and no one is working on it yet, you need to implement it yourself to see any chance of it getting merged. Otherwise, it is fairly unlikely that a feature as big as that will ever be merged. (One exception: if a maintainer misses this feature enough to go through the work of implementing it for you) There are 2000 issues here (at the time of writing). We are already swamped with what needs to be done.

However, if you were to implement it, here's a word of advice: Discuss your proposed solution in detail here. The description of what this issue entails is completely missing at the moment, as far as I can see. Otherwise, it can happen that you develop something whose architecture is absolutely not suited for Gitea.

That's necessary.

It would be great. We also suffer from the lack of such an opportunity. We are really waiting for someone to take up the implementation. With great hope. Thank you.

Yes it would be great... But since 2017, I no longer believe. Go ahead, unsubscribed from this issue and I have migrated my personnal repos.

Good luck

Can this function be easily implemented? For example, identifying the "/" in the warehouse name as a subdirectory also facilitates our management of internal warehouses within the organization Just like when we name our branch "feature/mod1", we get a feature group I believe that this change can also solve most of the requirements without the need to change how to modify the permissions of the subgroup

I could understand many users really like this feature and I also like it, however, by my understanding, it is nearly impossible to implement it at the moment. There are too many blockers for it.

go-gitea / gitea

Subgroups in Gitea #1872

Feature proposal