Subgroups in Gitea #770

@gayprogrammer commented on GitHub (Jun 14, 2017):

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 🙁

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?

@gayprogrammer commented on GitHub (Jun 14, 2017): 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?

GiteaMirror commented

@bkcsoft commented on GitHub (Jun 15, 2017):

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

@bkcsoft commented on GitHub (Jun 15, 2017): 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`

GiteaMirror commented

@bkcsoft commented on GitHub (Jun 15, 2017):

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

@bkcsoft commented on GitHub (Jun 15, 2017): 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

GiteaMirror commented

@ghost commented on GitHub (Jun 21, 2019):

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.

@ghost commented on GitHub (Jun 21, 2019): 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.

GiteaMirror commented

@tomdavidson commented on GitHub (Aug 20, 2019):

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.

@tomdavidson commented on GitHub (Aug 20, 2019): 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.

GiteaMirror commented

@Th3Whit3Wolf commented on GitHub (Sep 9, 2019):

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

@Th3Whit3Wolf commented on GitHub (Sep 9, 2019): Is there any estimable timeline when this could potentially be implemented? This would be super useful.

GiteaMirror commented

@lunny commented on GitHub (Sep 12, 2019):

@Th3Whit3Wolf No people are working on this.

@lunny commented on GitHub (Sep 12, 2019): @Th3Whit3Wolf No people are working on this.

GiteaMirror commented

@lakostin commented on GitHub (Jan 29, 2020):

Still no update?

@lakostin commented on GitHub (Jan 29, 2020): Still no update?

GiteaMirror commented

2025-11-02 03:35:57 -06:00

@6543 commented on GitHub (Jan 29, 2020):

dont see any

@6543 commented on GitHub (Jan 29, 2020): dont see any

GiteaMirror commented

@Nicolab commented on GitHub (Jul 6, 2020):

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?

@Nicolab commented on GitHub (Jul 6, 2020): 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?

GiteaMirror commented

2025-11-02 03:35:57 -06:00

@lafriks commented on GitHub (Jul 6, 2020):

It is planed but nobody does work on this currently

@lafriks commented on GitHub (Jul 6, 2020): It is planed but nobody does work on this currently

GiteaMirror commented

2025-11-02 03:35:57 -06:00

@Nicolab commented on GitHub (Jul 6, 2020):

Ok thanks for the confirmation

@Nicolab commented on GitHub (Jul 6, 2020): Ok thanks for the confirmation

GiteaMirror commented

@cwchristerw commented on GitHub (Aug 16, 2020):

Currently this feature is already available in Github

@cwchristerw commented on GitHub (Aug 16, 2020): Currently this feature is already available in Github

GiteaMirror commented

@Asherslab commented on GitHub (Nov 28, 2020):

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

@Asherslab commented on GitHub (Nov 28, 2020): would also love this feature. Our team is migrating from GitLab and this is a feature we sorely miss

GiteaMirror commented

@lafriks commented on GitHub (Dec 9, 2020):

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

@lafriks commented on GitHub (Dec 9, 2020): 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

GiteaMirror commented

@tomdavidson commented on GitHub (Dec 11, 2020):

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?

@tomdavidson commented on GitHub (Dec 11, 2020): 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?

GiteaMirror commented

@bjeanes commented on GitHub (Dec 11, 2020):

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.

@bjeanes commented on GitHub (Dec 11, 2020): 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.

GiteaMirror commented

@Nicolab commented on GitHub (Dec 12, 2020):

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

@Nicolab commented on GitHub (Dec 12, 2020): With or without URL path, the important thing is to have some repositories into subgroups.

GiteaMirror commented

@tomdavidson commented on GitHub (Dec 12, 2020):

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).

@tomdavidson commented on GitHub (Dec 12, 2020): 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).

GiteaMirror commented

@moqmar commented on GitHub (Feb 24, 2021):

Would you like any help with this feature @lafriks?

@moqmar commented on GitHub (Feb 24, 2021): Would you like any help with this feature @lafriks?

GiteaMirror commented

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

@mrexodia commented on GitHub (Mar 23, 2021):

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):

Is there a place available to fund this issue?

@mrexodia commented on GitHub (Mar 23, 2021): 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?

GiteaMirror commented

@lunny commented on GitHub (Mar 25, 2021):

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

@lunny commented on GitHub (Mar 25, 2021): ~You can visit https://www.bountysource.com/teams/gitea~

GiteaMirror commented

@z4lem commented on GitHub (Oct 26, 2021):

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.

@z4lem commented on GitHub (Oct 26, 2021): Has anyone an idea what happened to this feature request? Even if it was added to the 1.15 roadmap [#14477](https://github.com/go-gitea/gitea/issues/14477), it wasn't implemented. I also didnt found anything regarding a more fine grained orga/team handling in 1.16 [#16429](https://github.com/go-gitea/gitea/issues/16429). We would love to see this feature in gitea.

GiteaMirror commented

@lafriks commented on GitHub (Oct 26, 2021):

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

@lafriks commented on GitHub (Oct 26, 2021): It's on my individual backlog but have been quite busy lately so it will be done when it's done :D

GiteaMirror commented

@seboss666 commented on GitHub (Dec 4, 2021):

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

@seboss666 commented on GitHub (Dec 4, 2021): 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

GiteaMirror commented

@bryanpedini commented on GitHub (Feb 5, 2022):

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?

@bryanpedini commented on GitHub (Feb 5, 2022): > 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?

GiteaMirror commented

@seboss666 commented on GitHub (Feb 12, 2022):

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.

@seboss666 commented on GitHub (Feb 12, 2022): > > 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.

GiteaMirror commented

@gd197 commented on GitHub (Mar 4, 2022):

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

@gd197 commented on GitHub (Mar 4, 2022): 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

GiteaMirror commented

@wzqiang1332 commented on GitHub (May 7, 2022):

Expect this feature

@wzqiang1332 commented on GitHub (May 7, 2022): Expect this feature

GiteaMirror commented

@goyalyashpal commented on GitHub (Jul 20, 2022):

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

where??

@goyalyashpal commented on GitHub (Jul 20, 2022): > Currently this feature is already available in Github _@cwchristerw at https://github.com/go-gitea/gitea/issues/1872#issuecomment-674498347_ where??

GiteaMirror commented

https://telegram.org/apps#source-code

@goyalyashpal commented on GitHub (Jul 20, 2022):

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

(will post later)

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

@goyalyashpal commented on GitHub (Jul 20, 2022): the organizations hosted on github which release multiple applications for different different platforms are such a scattered mess (no offence). examples: (will post later) <details> https://telegram.org/apps#source-code **WithOUT subgroups** <tt>/   (github-root) </tt> <tt>├── tdlib </tt> <tt>│   ├── [td] </tt> <tt>│   ... </tt> <tt>├── TelegramMessenger </tt> <tt>│   ├── [Telegram-iOS] </tt> <tt>│   ... </tt> <tt>├── telegramdesktop </tt> <tt>│   ├── [tdesktop] </tt> <tt>│   ... </tt> <tt>├── [Telegram] </tt> <tt>├── [TelegramSwift] </tt> <tt>├── [tweb] </tt> <tt>├── [telegram-tt] </tt> <tt>├── [webogram] </tt> <tt>├── [telegram-react] </tt> <tt>├── [telegram-wp] </tt> <tt>... </tt> **With subgroups** <tt>/ (github-root) </tt> <tt>└── telegram </tt> <tt>   ├── tdlib </tt> <tt>   │   ├── [td] </tt> <tt>   │   ... </tt> <tt>   ├── android </tt> <tt>   │   ├── [Telegram] </tt> <tt>   │   ... </tt> <tt>   ├── iOS </tt> <tt>   │   ├── [Telegram-iOS] </tt> <tt>   │   ... </tt> <tt>   ├── desktop </tt> <tt>   │   ├── [tdesktop] </tt> <tt>   │   ... </tt> <tt>   ├── mac </tt> <tt>   │   ├── [TelegramSwift] </tt> <tt>   │   ... </tt> <tt>   ├── web </tt> <tt>   │   ├── [tweb] </tt> <tt>   │   ├── [telegram-tt] </tt> <tt>   │   ├── [webogram] </tt> <tt>   │   └── [telegram-react] </tt> <tt>   └── [telegram-wp] </tt> [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 </details>

GiteaMirror commented

@davama commented on GitHub (Aug 24, 2022):

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

@davama commented on GitHub (Aug 24, 2022): 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

GiteaMirror commented

@atommaki commented on GitHub (Sep 29, 2022):

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...

@atommaki commented on GitHub (Sep 29, 2022): 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...

GiteaMirror commented

@mrexodia commented on GitHub (Sep 29, 2022):

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…

@mrexodia commented on GitHub (Sep 29, 2022): > 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…

GiteaMirror commented

@tomdavidson commented on GitHub (Sep 29, 2022):

@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.

@tomdavidson commented on GitHub (Sep 29, 2022): @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.

GiteaMirror commented

@atommaki commented on GitHub (Sep 30, 2022):

@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...

@atommaki commented on GitHub (Sep 30, 2022): @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...

GiteaMirror commented

@atommaki commented on GitHub (Sep 30, 2022):

@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.

@atommaki commented on GitHub (Sep 30, 2022): @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.

GiteaMirror commented

@goyalyashpal commented on GitHub (Sep 30, 2022):

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.

@goyalyashpal commented on GitHub (Sep 30, 2022): 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. >

GiteaMirror commented

@lafriks commented on GitHub (Sep 30, 2022):

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.

@lafriks commented on GitHub (Sep 30, 2022): 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.

GiteaMirror commented

@mygit123hotmail commented on GitHub (Jun 9, 2023):

1.21 Will it be implemented? Very good. Multifunctional

@mygit123hotmail commented on GitHub (Jun 9, 2023): 1.21 Will it be implemented? Very good. Multifunctional

GiteaMirror commented

@lunny commented on GitHub (Jun 12, 2023):

1.21 Will it be implemented? Very good. Multifunctional

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

@lunny commented on GitHub (Jun 12, 2023): > 1.21 Will it be implemented? Very good. Multifunctional Why do you think that? Nobody are working on this.

GiteaMirror commented

@delvh commented on GitHub (Jun 12, 2023):

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.

@delvh commented on GitHub (Jun 12, 2023): 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.

GiteaMirror commented

@VAllens commented on GitHub (Apr 8, 2024):

That's necessary.

@VAllens commented on GitHub (Apr 8, 2024): That's necessary.

GiteaMirror commented

@KarenArzumanyan commented on GitHub (Apr 25, 2024):

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.

@KarenArzumanyan commented on GitHub (Apr 25, 2024): 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.

GiteaMirror commented

@Nicolab commented on GitHub (Apr 25, 2024):

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

@Nicolab commented on GitHub (Apr 25, 2024): 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

GiteaMirror commented

@meng-plus commented on GitHub (Apr 25, 2024):

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

@meng-plus commented on GitHub (Apr 25, 2024): 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

GiteaMirror commented

@wxiaoguang commented on GitHub (Apr 25, 2024):

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.

@wxiaoguang commented on GitHub (Apr 25, 2024): 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.

GiteaMirror commented

@atommaki commented on GitHub (May 16, 2024):

.... it is nearly impossible to implement it at the moment. There are too many blockers for it.

So the work could start by making a list of these blocking issues.

@atommaki commented on GitHub (May 16, 2024): > .... it is nearly impossible to implement it at the moment. There are too many blockers for it. So the work could start by making a list of these blocking issues.

GiteaMirror commented

@Frankkkkk commented on GitHub (Jul 3, 2024):

@remram44 just curious: why are you "downvoting" every person that agrees that this feature could be useful?

@Frankkkkk commented on GitHub (Jul 3, 2024): @remram44 just curious: why are you "downvoting" every person that agrees that this feature could be useful?

GiteaMirror commented

@remram44 commented on GitHub (Jul 3, 2024):

Agreeing is done with the 👍 button. Posting "me too" just spams everyone's inbox with emails that have no content. Don't do it.

@remram44 commented on GitHub (Jul 3, 2024): Agreeing is done with the :+1: button. Posting "me too" just spams everyone's inbox with emails that have no content. Don't do it.

GiteaMirror commented

@Nicolab commented on GitHub (Jul 4, 2024):

It's not just "me too" downvoted. Useless.

@Nicolab commented on GitHub (Jul 4, 2024): It's not just "me too" downvoted. Useless.

GiteaMirror commented

@ghost commented on GitHub (Oct 17, 2024):

8 years it has been. Can we setup a bounty for that feature ?
(also making this alone doesn't seems possible, it has to be a team work)

@ghost commented on GitHub (Oct 17, 2024): 8 years it has been. Can we setup a bounty for that feature ? (also making this alone doesn't seems possible, it has to be a team work)

GiteaMirror commented

@lunny commented on GitHub (Dec 14, 2024):

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

@lunny commented on GitHub (Dec 14, 2024): Would you accept a router like `org1/-/group1/repo1`. Only one level group, no multiple groups supported.

GiteaMirror commented

@VAllens commented on GitHub (Dec 15, 2024):

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

When we implement the concept and design of groups,
why not be able to support multiple tiers easily?

But anyway, it's a very good start!

@VAllens commented on GitHub (Dec 15, 2024): > Would you accept a router like `org1/-/group1/repo1`. Only one level group, no multiple groups supported. When we implement the concept and design of groups, why not be able to support multiple tiers easily? But anyway, it's a very good start!

GiteaMirror commented

@lunny commented on GitHub (Dec 15, 2024):

Yes, in the future, we plan to support structures like org1/-/group1/subgroup1/repo1. However, initially, we may limit support to a single tier to make it easier to be implemented.

@lunny commented on GitHub (Dec 15, 2024): Yes, in the future, we plan to support structures like org1/-/group1/subgroup1/repo1. However, initially, we may limit support to a single tier to make it easier to be implemented.

GiteaMirror commented

@delvh commented on GitHub (Dec 15, 2024):

Edgecases

Note, however, that before we implement anything like that, we must first think about the permission system.
This can only work if we define the permission system correctly.
There are quite a few edge cases I can think of at the top of my head:
How do we model teams then?
Is a team a unit across the entire organization?
Is a team only available for a specific subgroup?
Do we throw out teams entirely and model them as subgroups instead?
If the team is a cross-organizational unit, how are conflicting permissions handled?
I.e. user alice is part of group group and team team.
group is not permitted access to repo x. team however is. Is alice now able to see x, or no?
If we don't throw out the definition of a team with this, then what's even the difference between a subgroup and a team? Both should be able to do pretty much the same except the team is much more flexible in its permission system.

Is this worth it?

It's exactly these questions that make me ask myself if this feature is really worth it?
As far as I can see, a much simpler solution is to just use the term organization much more loosely (to compare it to bitbucket, simply use it as a project, so a set of connected repos that perhaps have a small "user filter" so that it is only accessible to some people).

Suggestion

I think at the heart of this discussion, there is a conflict between what is stated here and what is actually needed:
The proposed problem is to make orgs even more hierarchical.
I disagree with that approach: That makes a lot of problems for marginal gains.

What I think is needed instead is the following:
We need to improve the UI to allow much easier copying of the hierarchical structure:
For example, if it was possible to copy the hierarchy of one organization recursively (i.e. the new org receives the same users and teams as the old org) without copying the repos, this feature won't be needed anymore:
All of a sudden, you can achieve the same thing as with subgroups which are an exorbitant amount of work with a single button click to generate a new organization from an existing one.

Or am I missing something here?
Is there any usecase that isn't possible with an easy copy hierarchy UI that is possible with a we are 20 hierarchical layers deeply nested approach?

This UI would need to do two things:

Allowing to generate a new organization from an existing one (required)
one- or two way sync between organization/team members. (optional, couldn't that be achieved using LDAP filters or something like that that determine group membership?)

@delvh commented on GitHub (Dec 15, 2024): ## Edgecases Note, however, that before we implement anything like that, we must first think about the permission system. This can only work if we define the permission system correctly. There are quite a few edge cases I can think of at the top of my head: How do we model teams then? Is a team a unit across the entire organization? Is a team only available for a specific subgroup? Do we throw out teams entirely and model them as subgroups instead? If the team is a cross-organizational unit, how are conflicting permissions handled? I.e. user `alice` is part of group `group` and team `team`. `group` is not permitted access to repo `x`. `team` however is. Is `alice` now able to see `x`, or no? If we don't throw out the definition of a `team` with this, then what's even the difference between a `subgroup` and a `team`? Both should be able to do pretty much the same except the team is much more flexible in its permission system. ## Is this worth it? It's exactly these questions that make me ask myself if this feature is really worth it? As far as I can see, a much simpler solution is to just use the term `organization` much more loosely (to compare it to bitbucket, simply use it as a `project`, so a set of connected repos that perhaps have a small "user filter" so that it is only accessible to some people). ## Suggestion I think at the heart of this discussion, there is a conflict between what is stated here and what is actually needed: The proposed problem is to make orgs even more hierarchical. I disagree with that approach: That makes **a lot** of problems for marginal gains. What I think is needed instead is the following: We need to improve the UI to allow much easier copying of the hierarchical structure: For example, if it was possible to copy the hierarchy of one organization recursively (i.e. the new org receives the same users and teams as the old org) without copying the repos, this feature won't be needed anymore: All of a sudden, you can achieve the same thing as with subgroups which are an exorbitant amount of work with a single button click to generate a new organization from an existing one. Or am I missing something here? Is there any usecase that isn't possible with an easy `copy hierarchy` UI that is possible with a `we are 20 hierarchical layers deeply nested` approach? This UI would need to do two things: 1. Allowing to generate a new organization from an existing one (required) 2. one- or two way sync between organization/team members. (optional, couldn't that be achieved using LDAP filters or something like that that determine group membership?)

GiteaMirror commented

@bkilinc commented on GitHub (Dec 15, 2024):

I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc.

@bkilinc commented on GitHub (Dec 15, 2024): I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc.

GiteaMirror commented

@lunny commented on GitHub (Dec 15, 2024):

Maybe we can support a custom filter on the repositories list, this approach will not touch any other infrastructure. The team can add repositories or a repository filter(we can have a new name for that). And also a default filter can be assigned to a team or a user in this organization. But I don't know whether this satisfy most of your requirements.

@lunny commented on GitHub (Dec 15, 2024): Maybe we can support a custom filter on the repositories list, this approach will not touch any other infrastructure. The team can add repositories or a repository filter(we can have a new name for that). And also a default filter can be assigned to a team or a user in this organization. But I don't know whether this satisfy most of your requirements.

GiteaMirror commented

@VAllens commented on GitHub (Dec 16, 2024):

I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc.

For individual users, there is no team, no organization, so the existing functionality is perfectly adequate.
For enterprises, there are organizations, departments, teams with cross-departmental collaboration, and projects with cross-departmental collaboration, so the existing functionality is not sufficient.

@VAllens commented on GitHub (Dec 16, 2024): > I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc. For individual users, there is no team, no organization, so the existing functionality is perfectly adequate. For enterprises, there are organizations, departments, teams with cross-departmental collaboration, and projects with cross-departmental collaboration, so the existing functionality is not sufficient.

GiteaMirror commented

@KarenArzumanyan commented on GitHub (Dec 16, 2024):

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

Several levels of grouping are not often encountered in practice.
One level seems sufficient for 90% of cases.
At least one level is very necessary.
For example, there is a large project and several subprojects.
It is convenient to set up access to the group at once (this is very important).
It is convenient not to mix it visually with other projects.

A very good start with one level, maybe even sufficient.

@KarenArzumanyan commented on GitHub (Dec 16, 2024): > Would you accept a router like `org1/-/group1/repo1`. Only one level group, no multiple groups supported. Several levels of grouping are not often encountered in practice. One level seems sufficient for 90% of cases. At least one level is very necessary. For example, there is a large project and several subprojects. It is convenient to set up access to the group at once (this is very important). It is convenient not to mix it visually with other projects. A very good start with one level, maybe even sufficient.

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Dec 16, 2024):

one note on that notation though.. if repos belong to groups - and thats the same as "permissions" ? - then we agree repos that needs to be accessed by other groups - needs to be outside any group, or?
IMHO the team perms currently there is "not too bad" (although confusing that you can't decide per repo you add them to - what that teams perms are there)
So whats IMHO needed is only the visual grouping.. not access groups.. so I'd not call it groups if its ONLY for "visual filtering".. then it should merely be called category - as its not about permissions ?

@KlavsKlavsen commented on GitHub (Dec 16, 2024): one note on that notation though.. if repos belong to groups - and thats the same as "permissions" ? - then we agree repos that needs to be accessed by other groups - needs to be outside any group, or? IMHO the team perms currently there is "not too bad" (although confusing that you can't decide per repo you add them to - what that teams perms are there) So whats IMHO needed is only the visual grouping.. not access groups.. so I'd not call it groups if its ONLY for "visual filtering".. then it should merely be called category - as its not about permissions ?

GiteaMirror commented

@bkilinc commented on GitHub (Dec 16, 2024):

For individual users, there is no team, no organization, so the existing functionality is perfectly adequate.

No, existing functionality is not adequate, if I have 200 repositories for example. I need to organize them in sub projects. There is no groups at this time, but there may be. so I should be able to give permissions to groups.

@bkilinc commented on GitHub (Dec 16, 2024): > For individual users, there is no team, no organization, so the existing functionality is perfectly adequate. No, existing functionality is not adequate, if I have 200 repositories for example. I need to organize them in sub projects. There is no groups at this time, but there may be. so I should be able to give permissions to groups.

GiteaMirror commented

@mrexodia commented on GitHub (Dec 16, 2024):

I know for a fact there are at least two companies that are not migrating from Gitlab to Gitea because there are no groups for organizational purposes. Groups are purely used to organize your organization's (aka development team's) repositories and one level is more than enough. This is already useful, purely so you do not have 200 repositories in a single list.

Making things like permissions/issue lists/whatever a prerequisite is just scope creep and will only add more and more delays to this feature which people have been requesting for almost 8 years(!) Once the basics are implemented you can always completely redo the feature with overengineered permission systems and other bells and whistles and spend another 8 years on that if necessary, but I think getting something out quickly will make 🤷🏻‍♂️

@mrexodia commented on GitHub (Dec 16, 2024): I know for a fact there are at least two companies that are not migrating from Gitlab to Gitea because there are no groups for organizational purposes. Groups are purely used to organize your organization's (aka development team's) repositories and one level is more than enough. This is already useful, purely so you do not have 200 repositories in a single list. Making things like permissions/issue lists/whatever a prerequisite is just scope creep and will only add more and more delays to this feature which people have been requesting for almost 8 years(!) Once the basics are implemented you can always completely redo the feature with overengineered permission systems and other bells and whistles and spend another 8 years on that if necessary, but I think getting something out quickly will make 🤷🏻‍♂️

GiteaMirror commented

2025-11-02 03:36:10 -06:00

@Frankkkkk commented on GitHub (Dec 16, 2024):

I totally agree. Same here. We wanted to migrate and "just" needed a simple hierarchy : /project-A/component1/code_a , and having 2 level "groups" would have been nice too. Of course there were other issues (the most important one was CI token rights to push on registries), but groups were one of them

@Frankkkkk commented on GitHub (Dec 16, 2024): I totally agree. Same here. We wanted to migrate and "just" needed a simple hierarchy : /project-A/component1/code_a , and having 2 level "groups" would have been nice too. Of course there were other issues (the most important one was CI token rights to push on registries), but groups were one of them

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Dec 16, 2024):

If I wasn't clear - yes. Merely a categization of repos (1 level is fine) - so you can work with a "subset of repos" in a list - would be more than enough.
If that "category" - corresponds to what a team manages of repos - then one an just add those repos to the teams list of repos.. its not a big problem - so the simple solution helps a LOT - and then build on that.
the category could also match a project - or departments with multiple teams or whatever.. just having category (and cefault listing showing category name - not all repos below it) would be a very useful improvement.

@KlavsKlavsen commented on GitHub (Dec 16, 2024): If I wasn't clear - yes. Merely a categization of repos (1 level is fine) - so you can work with a "subset of repos" in a list - would be more than enough. If that "category" - corresponds to what a team manages of repos - then one an just add those repos to the teams list of repos.. its not a big problem - so the simple solution helps a LOT - and then build on that. the category could also match a project - or departments with multiple teams or whatever.. just having category (and cefault listing showing category name - not all repos below it) would be a very useful improvement.

GiteaMirror commented

2025-11-02 03:36:10 -06:00

@algora-pbc[bot] commented on GitHub (Dec 21, 2024):

💎 $80 bounty • Frank Villaro-Dixon

💎 $100 bounty • jozek.woloch

Steps to solve:

Start working: Comment /attempt #1872 with your implementation plan
Submit work: Create a pull request including /claim #1872 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to go-gitea/gitea!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @GamerGirlandCo	Dec 25, 2024, 1:20:08 AM	WIP

@algora-pbc[bot] commented on GitHub (Dec 21, 2024): ## 💎 $80 bounty [• Frank Villaro-Dixon](https://console.algora.io/org/Frankkkkk) ## 💎 $100 bounty [• jozek.woloch](https://console.algora.io/org/jozek.woloch) ### Steps to solve: 1. **Start working**: Comment `/attempt #1872` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #1872` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://docs.algora.io/bounties/payments#supported-countries-regions) Thank you for contributing to go-gitea/gitea! **[Add a bounty](https://console.algora.io/org/Frankkkkk/bounties/community?fund=go-gitea%2Fgitea%231872)** • **[Share on socials](https://twitter.com/intent/tweet?text=%24180+bounty%21+%F0%9F%92%8E+https%3A%2F%2Fgithub.com%2Fgo-gitea%2Fgitea%2Fissues%2F1872&related=algoraio)** <table> <thead> <tr> <th>Attempt</th> <th>Started (GMT+0)</th> <th>Solution</th> </tr> </thead> <tbody> <tr> <td>🟢 @GamerGirlandCo</td> <td>Dec 25, 2024, 1:20:08 AM</td> <td>WIP</td> </tr> </tbody> </table>

GiteaMirror commented

2025-11-02 03:36:10 -06:00

@GamerGirlandCo commented on GitHub (Dec 25, 2024):

/attempt #1872

as with gitlab, this will be limited to 20 levels of nesting, which should be more than enough for most use cases
gitlab has the ability to create secrets and runners isolated to a specific group, so whatever model the secret table uses will have to be updated. same applies to runners
subgroups should be able to be mentioned; need to update the incoming message handlers to account for that

Options

Cancel my attempt

@GamerGirlandCo commented on GitHub (Dec 25, 2024): /attempt #1872 - as with gitlab, this will be limited to 20 levels of nesting, which should be more than enough for most use cases - gitlab has the ability to create secrets and runners isolated to a specific group, so whatever model the `secret` table uses will have to be updated. same applies to runners - subgroups should be able to be mentioned; need to update the incoming message handlers to account for that <div id="algora-attempt" /> <details> <summary>Options</summary> <ul> <li> <a href="https://console.algora.io/api/bounties/cm4y7isbh0002ld03hx7d2y48/cancel-attempt"> Cancel my attempt </a> </li> </ul> </details>

GiteaMirror commented

@lunny commented on GitHub (Dec 25, 2024):

Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request.

@lunny commented on GitHub (Dec 25, 2024): Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request.

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Dec 31, 2024):

Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request.

@lunny here's a checklist i made over the last few days encompassing tasks that need to be completed

backend
- models
  - existing (to update)
    mostly, this entails adding a GroupID field to the following structs, and updating their accompanying Find...Options types to enable searching by group id
    - repository
    - action runner
    - action variable
    - action secret
  - new (to add)
    - group
    - group-team relation
      stores a team’s access level to a group
    - group unit
      like a repository unit, but grants or denies access to a specific unit at the group level. will override unit permissions defined on a team
- API
  access to these endpoints is governed by read:organization and write:organization scopes
  - POST /org/{org}/groups/new → create a new group at the root level of an org
  - /org/{org}/groups/{group_id}
    - GET → retrieves the group
    - PATCH → updates the group's name and/or description
  - POST /org/{org}/groups/{group_id}/new → creates a new subgroup inside a group
  - POST /org/{org}/groups/{group_id}/move → moves a group to different group in the same organization, or to the root level if newParent is null or 0
  - POST /{username}/{reponame}/groups/move → moves a repository to a different group within an organization, or to the root level if newParent is null or 0
- misc updates (high-level, non-exhaustive)
  - update GetUserRepoPermission function to take into account group permissions
  - update GetTeamRepositories to take into account group permissions
  - update condition builder functions in models/repo/repo_list.go to check for group access
frontend
- templates
  - create a sidebar containing a tree of links to organization groups and repos accessible to the currently logged-in user. this list should ideally be reorderable
- pages
  - /{org}/groups/{group_id} → group home
  - /org/{org}/groups/{group_id}/teams → list of teams which have explicit access to the group. explicit access to the group may be granted via this page to teams that don't already have it
    - /org/{org}/groups/{group_id}/teams/edit → a page to edit a team’s permissions in a group. should require actor to have admin or owner privileges
  - /org/{org}/groups/{group_id}/settings → a settings page with the following
    - group-specific action configuration (variables, secrets, runners)
    - ‘display’ settings, such as
      - group icon
      - name
      - description

@GamerGirlandCo commented on GitHub (Dec 31, 2024): > Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request. @lunny here's a checklist i made over the last few days encompassing tasks that need to be completed - [ ] backend - [ ] models - [ ] existing (to update) mostly, this entails adding a `GroupID` field to the following structs, and updating their accompanying `Find...Options` types to enable searching by group id - [ ] repository - [ ] action runner - [ ] action variable - [ ] action secret - [ ] new (to add) - [ ] group - [ ] group-team relation stores a team’s [access level](https://github.com/go-gitea/gitea/blob/main/models%2Fperm%2Faccess_mode.go#L14) to a group - [ ] group unit like a repository unit, but grants or denies access to a specific unit at the group level. will override unit permissions defined on a [team](https://github.com/go-gitea/gitea/blob/main/models%2Forganization%2Fteam_unit.go) - [ ] API access to these endpoints is governed by `read:organization` and `write:organization` scopes - [ ] POST `/org/{org}/groups/new` → create a new group at the root level of an org - [ ] `/org/{org}/groups/{group_id}` - [ ] GET → retrieves the group - [ ] PATCH → updates the group's name and/or description - [ ] POST `/org/{org}/groups/{group_id}/new` → creates a new subgroup inside a group - [ ] POST `/org/{org}/groups/{group_id}/move` → moves a group to different group in the same organization, or to the root level if `newParent` is null or 0 - [ ] POST `/{username}/{reponame}/groups/move` → moves a repository to a different group within an organization, or to the root level if `newParent` is null or 0 - [ ] misc updates (high-level, non-exhaustive) - [ ] update [GetUserRepoPermission](https://github.com/go-gitea/gitea/blob/main/models/perm/access/repo_permission.go#L193) function to take into account group permissions - [ ] update [GetTeamRepositories](https://github.com/go-gitea/gitea/blob/main/models/repo/org_repo.go#L30) to take into account group permissions - [ ] update condition builder functions in [models/repo/repo_list.go](https://github.com/go-gitea/gitea/blob/main/models/repo/repo_list.go) to check for group access - [ ] frontend - [ ] templates - [ ] create a sidebar containing a tree of links to organization groups and repos accessible to the currently logged-in user. this list should ideally be reorderable - [ ] pages - [ ] `/{org}/groups/{group_id}` → group home - [ ] `/org/{org}/groups/{group_id}/teams` → list of teams which have explicit access to the group. explicit access to the group may be granted via this page to teams that don't already have it - [ ] `/org/{org}/groups/{group_id}/teams/edit` → a page to edit a team’s permissions in a group. should require actor to have admin or owner privileges - [ ] `/org/{org}/groups/{group_id}/settings` → a settings page with the following - [ ] group-specific action configuration (variables, secrets, runners) - [ ] ‘display’ settings, such as - [ ] group icon - [ ] name - [ ] description

GiteaMirror commented

@Frankkkkk commented on GitHub (Dec 31, 2024):

Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers

@Frankkkkk commented on GitHub (Dec 31, 2024): Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Dec 31, 2024):

Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers

yes it does, up to 20 levels :)

and on group pages, there will be a breadcrumb showing the group's ancestors

@GamerGirlandCo commented on GitHub (Dec 31, 2024): > Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers yes it does, up to 20 levels :) and on group pages, there will be a breadcrumb showing the group's ancestors

GiteaMirror commented

@wxiaoguang commented on GitHub (Jan 1, 2025):

Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render)

And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better.

@wxiaoguang commented on GitHub (Jan 1, 2025): Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render) And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better.

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Jan 1, 2025):

Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render)

my implementation doesn't modify the existing URL format.

And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better.

i guess that's fair. though i'd like to think that working on this for the past week (give or take) is teaching me about gitea's internals quite well :)

@GamerGirlandCo commented on GitHub (Jan 1, 2025): > Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render) my implementation doesn't modify the existing URL format. > And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better. i guess that's fair. though i'd like to think that working on this for the past week (give or take) is teaching me about gitea's internals quite well :)

GiteaMirror commented

@miztizm commented on GitHub (Feb 2, 2025):

This is a great idea! Voting for this!

@miztizm commented on GitHub (Feb 2, 2025): This is a great idea! Voting for this!

GiteaMirror commented

@ttimasdf commented on GitHub (Feb 6, 2025):

I'd like to share some insights from a different view point.

Github does not support subgroups. Microsoft prefers monorepo, where all sub-projects are contained within a single large Git repo, and they develop tools to better manage monorepos (saying scalar).

I know this is approach is not for everyone, but at least a workaround that we could try at the time?

@ttimasdf commented on GitHub (Feb 6, 2025): I'd like to share some insights from a different view point. Github does *not* support subgroups. Microsoft prefers monorepo, where all sub-projects are contained within a single large Git repo, and they develop tools to better manage monorepos (saying [scalar](https://github.com/microsoft/scalar)). I know this is approach is not for everyone, but at least a workaround that we could try at the time?

GiteaMirror commented

@mrmelon54 commented on GitHub (Feb 14, 2025):

Having a monorepo is very different from lots of smaller repos stored in subgroups. What if the projects are related but don't share any source code at all. It could potentially be worse for development to have them in a big monorepo.

@mrmelon54 commented on GitHub (Feb 14, 2025): Having a monorepo is very different from lots of smaller repos stored in subgroups. What if the projects are related but don't share any source code at all. It could potentially be worse for development to have them in a big monorepo.

GiteaMirror commented

@algora-pbc[bot] commented on GitHub (Jun 14, 2025):

💎 $250 bounty • David Flanagan

💎 $100 bounty • jozek.woloch

💎 $80 bounty • Frank

Steps to solve:

Start working: Comment /attempt #1872 with your implementation plan
Submit work: Create a pull request including /claim #1872 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

To claim a bounty, you need to provide a short demo video of your changes in your pull request
If anything is unclear, ask for clarification before starting as this will help avoid potential rework
Low quality AI PRs will not receive review and will be closed
Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt	Started (UTC)	Solution	Actions
🟢 @GamerGirlandCo	Dec 25, 2024, 01:20:08 AM	WIP

@algora-pbc[bot] commented on GitHub (Jun 14, 2025): ## 💎 $250 bounty [• David Flanagan](https://algora.io/rawkode) ## 💎 $100 bounty [• jozek.woloch](https://algora.io/jozek.woloch) ## 💎 $80 bounty [• Frank](https://algora.io/Frankkkkk) ### Steps to solve: 1. **Start working**: Comment `/attempt #1872` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #1872` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @GamerGirlandCo | Dec 25, 2024, 01:20:08 AM | WIP | |

GiteaMirror commented

@algora-pbc[bot] commented on GitHub (Jun 14, 2025):

💎 $50 bounty • Klexx

💎 $250 bounty • David Flanagan

💎 $100 bounty • jozek.woloch

💎 $80 bounty • Frank

Steps to solve:

Start working: Comment /attempt #1872 with your implementation plan
Submit work: Create a pull request including /claim #1872 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

To claim a bounty, you need to provide a short demo video of your changes in your pull request
If anything is unclear, ask for clarification before starting as this will help avoid potential rework
Low quality AI PRs will not receive review and will be closed
Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt	Started (UTC)	Solution	Actions
🟢 @GamerGirlandCo	Dec 25, 2024, 01:20:08 AM	WIP

@algora-pbc[bot] commented on GitHub (Jun 14, 2025): ## 💎 $50 bounty [• Klexx](https://algora.io/Klexx) ## 💎 $250 bounty [• David Flanagan](https://algora.io/rawkode) ## 💎 $100 bounty [• jozek.woloch](https://algora.io/jozek.woloch) ## 💎 $80 bounty [• Frank](https://algora.io/Frankkkkk) ### Steps to solve: 1. **Start working**: Comment `/attempt #1872` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #1872` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @GamerGirlandCo | Dec 25, 2024, 01:20:08 AM | WIP | |

GiteaMirror commented

@algora-pbc[bot] commented on GitHub (Jun 17, 2025):

💎 $500 bounty • Julien-Pierre Avérous

💎 $50 bounty • Klexx

💎 $250 bounty • David Flanagan

💎 $100 bounty • jozek.woloch

💎 $80 bounty • Frank

Steps to solve:

Start working: Comment /attempt #1872 with your implementation plan
Submit work: Create a pull request including /claim #1872 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

To claim a bounty, you need to provide a short demo video of your changes in your pull request
If anything is unclear, ask for clarification before starting as this will help avoid potential rework
Low quality AI PRs will not receive review and will be closed
Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt	Started (UTC)	Solution	Actions
🟢 @GamerGirlandCo	Dec 25, 2024, 01:20:08 AM	WIP

@algora-pbc[bot] commented on GitHub (Jun 17, 2025): ## 💎 $500 bounty [• Julien-Pierre Avérous](https://algora.io/javerous) ## 💎 $50 bounty [• Klexx](https://algora.io/Klexx) ## 💎 $250 bounty [• David Flanagan](https://algora.io/rawkode) ## 💎 $100 bounty [• jozek.woloch](https://algora.io/jozek.woloch) ## 💎 $80 bounty [• Frank](https://algora.io/Frankkkkk) ### Steps to solve: 1. **Start working**: Comment `/attempt #1872` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #1872` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @GamerGirlandCo | Dec 25, 2024, 01:20:08 AM | WIP | |

GiteaMirror commented

@kinosang commented on GitHub (Jul 15, 2025):

Hi all,

when adding support for subgroups, should we treat them purely as a UI‑level concept — meaning we wouldn’t touch any actions, permissions or team functionality — or opt for a more powerful implementation? If we go the latter route, do we plan to alter clone URLs to include the subgroup path, or keep existing URLs unchanged?

@kinosang commented on GitHub (Jul 15, 2025): Hi all, when adding support for subgroups, should we treat them purely as a UI‑level concept — *meaning we wouldn’t touch any actions, permissions or team functionality* — or opt for a more powerful implementation? If we go the latter route, do we plan to alter clone URLs to include the subgroup path, or keep existing URLs unchanged?

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Aug 13, 2025):

i'm going to split this feature up into several chunks, and submit a separate pull request for each.

base
this includes the creation of the related types and API routes
frontend
this includes page templates, web routes and javascript for viewing, reordering, creating and editing groups
actions
features such as group-scoped runners, runner tokens and secrets, as well as the related UIs for editing them, will be included here

@GamerGirlandCo commented on GitHub (Aug 13, 2025): i'm going to split this feature up into several chunks, and submit a separate pull request for each. - **base** this includes the creation of the related types and API routes - **frontend** this includes page templates, web routes and javascript for viewing, reordering, creating and editing groups - **actions** features such as group-scoped runners, runner tokens and secrets, as well as the related UIs for editing them, will be included here

GiteaMirror commented

@lunny commented on GitHub (Aug 13, 2025):

Thank you for considering contributions. Please have a detailed proposal to get acceptance from maintainers. From my side, I think first of all, the repository disk structure needs to be changed. A new column about the relative storage path should be added in the repository database table. Because the repository a/b/c should not be stored under a/b, otherwise it will result in many conflicts.

@lunny commented on GitHub (Aug 13, 2025): Thank you for considering contributions. Please have a detailed proposal to get acceptance from maintainers. From my side, I think first of all, the repository disk structure needs to be changed. A new column about the relative storage path should be added in the repository database table. Because the repository a/b/c should not be stored under a/b, otherwise it will result in many conflicts.

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Aug 13, 2025):

From my side, I think first of all, the repository disk structure needs to be changed. A new column about the relative storage path should be added in the repository database table. Because the repository a/b/c should not be stored under a/b, otherwise it will result in many conflicts.

my implementation does not touch repository urls or how they're stored.

i've simply added GroupID and GroupSortOrder fields to the Repository model, which dictate which group a repo belongs to and its index within that group. from there, the frontend displays breadcrumbs at the top of the page, as well as a sidebar showing the entire group hierarchy for easy navigation.

@GamerGirlandCo commented on GitHub (Aug 13, 2025): > From my side, I think first of all, the repository disk structure needs to be changed. A new column about the relative storage path should be added in the repository database table. Because the repository a/b/c should not be stored under a/b, otherwise it will result in many conflicts. my implementation does not touch repository urls or how they're stored. i've simply added `GroupID` and `GroupSortOrder` fields to the `Repository` model, which dictate which group a repo belongs to and its index within that group. from there, the frontend displays breadcrumbs at the top of the page, as well as a sidebar showing the entire group hierarchy for easy navigation.

GiteaMirror commented

@netthier commented on GitHub (Aug 17, 2025):

my implementation does not touch repository urls or how they're stored.

@GamerGirlandCo How does your proposal handle repositories with the same name but in different subgroups of the same organization?
One of the big and main advantages of groups, at least for me, is that they act as a kind of namespace, allowing me to re-use repository names within an organization, differentiated by their parent group (e.g. GitLab allows this).
If the parent group is only a piece of metadata in the database and the on-disk format stays the same, the repos would collide.

And as suggested by others it might be prudent to first post an RFC with a detailed description of your proposal before spending too much time implementing something that might not be accepted on design grounds 🤔

@netthier commented on GitHub (Aug 17, 2025): > my implementation does not touch repository urls or how they're stored. @GamerGirlandCo How does your proposal handle repositories with the same name but in different subgroups of the same organization? One of the big and *main* advantages of groups, at least for me, is that they act as a kind of namespace, allowing me to re-use repository names within an organization, differentiated by their parent group (e.g. GitLab allows this). If the parent group is only a piece of metadata in the database and the on-disk format stays the same, the repos would collide. And as suggested by others it might be prudent to first post an RFC with a detailed description of your proposal before spending too much time implementing something that might not be accepted on design grounds 🤔

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Aug 17, 2025):

my implementation does not touch repository urls or how they're stored.

@GamerGirlandCo How does your proposal handle repositories with the same name but in different subgroups of the same organization? One of the big and main advantages of groups, at least for me, is that they act as a kind of namespace, allowing me to re-use repository names within an organization, differentiated by their parent group (e.g. GitLab allows this). If the parent group is only a piece of metadata in the database and the on-disk format stays the same, the repos would collide.

And as suggested by others it might be prudent to first post an RFC with a detailed description of your proposal before spending too much time implementing something that might not be accepted on design grounds 🤔

thanks for your feedback! i've implemented changes to repo layout on disk. the repos will now be stored as {RepoRoot}/{org}/{groupID}/{repoName}, or, if the repo isn't part of a group, it will simply be stored as {RepoRoot}/{org}/{repoName}.

@GamerGirlandCo commented on GitHub (Aug 17, 2025): > > my implementation does not touch repository urls or how they're stored. > > [@GamerGirlandCo](https://github.com/GamerGirlandCo) How does your proposal handle repositories with the same name but in different subgroups of the same organization? One of the big and _main_ advantages of groups, at least for me, is that they act as a kind of namespace, allowing me to re-use repository names within an organization, differentiated by their parent group (e.g. GitLab allows this). If the parent group is only a piece of metadata in the database and the on-disk format stays the same, the repos would collide. > > And as suggested by others it might be prudent to first post an RFC with a detailed description of your proposal before spending too much time implementing something that might not be accepted on design grounds 🤔 thanks for your feedback! i've implemented changes to repo layout on disk. the repos will now be stored as `{RepoRoot}/{org}/{groupID}/{repoName}`, or, if the repo isn't part of a group, it will simply be stored as `{RepoRoot}/{org}/{repoName}`.

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Aug 20, 2025):

@lunny is it okay if i modify the makefile and add a tool to generate versions of the repo routes with a /group/{group_id} segment for the swagger spec?

this is to ensure that in the future, people who update the repo routes (the ones that start with /repos/{owner}/{repo}) don't have to do the work of writing two functions that do the exact same thing and annotate them with comments so it gets picked up by go-swagger.

@GamerGirlandCo commented on GitHub (Aug 20, 2025): @lunny is it okay if i modify the makefile and add a tool to generate versions of the repo routes with a `/group/{group_id}` segment for the swagger spec? this is to ensure that in the future, people who update the repo routes (the ones that start with `/repos/{owner}/{repo}`) don't have to do the work of writing two functions that do the exact same thing *and* annotate them with comments so it gets picked up by go-swagger.

GiteaMirror commented

@lunny commented on GitHub (Aug 20, 2025):

I think make generate-swagger can already do that?

@lunny commented on GitHub (Aug 20, 2025): I think `make generate-swagger` can already do that?

GiteaMirror commented

@GamerGirlandCo commented on GitHub (Aug 22, 2025):

I think make generate-swagger can already do that?

i did a ton of research and it can't, not without duplicating //swagger:operation comments for every API endpoint that starts with /repos/{owner}/{repo}. i wrote a small tool to automate this, meant to be run during the make generate-swagger target:

build_tools/swagger/main.go

//go:generate go run main.go ../../

package main

import (
	"encoding/json"
	"log"
	"os"
	"path/filepath"
	"regexp"
)

var rxPath = regexp.MustCompile("(?m)^(/repos/\\{owner})/(\\{repo})")

func generatePaths(root string) map[string]any {
	pathData := make(map[string]any)
	endpoints := make(map[string]any)
	fileToRead, err := filepath.Rel(root, "./templates/swagger/v1_json.tmpl")
	if err != nil {
		log.Fatal(err)
	}
	swaggerBytes, err := os.ReadFile(fileToRead)
	if err != nil {
		log.Fatal(err)
	}
	raw := make(map[string]any)
	err = json.Unmarshal(swaggerBytes, &raw)
	if err != nil {
		log.Fatal(err)
	}
	paths := raw["paths"].(map[string]any)
	for k, v := range paths {
		if !rxPath.MatchString(k) {
			// skip if this endpoint does not start with `/repos/{owner}/{repo}`
			continue
		}
		// generate new endpoint path with `/group/{group_id}` in between the `owner` and `repo` params
		nk := rxPath.ReplaceAllString(k, "$1/group/{group_id}/$2")
		methodMap := v.(map[string]any)

		for method, methodSpec := range methodMap {
			specMap := methodSpec.(map[string]any)
			params := specMap["parameters"].([]any)
			params = append(params, map[string]any{
				"description": "group ID of the repo",
				"name":        "group_id",
				"type":        "integer",
				"format":      "int64",
				"required":    true,
				"in":          "path",
			})
			// i believe for...range loops create copies of each item that's iterated over,
			// so we need to take extra care to ensure we're mutating the original map entry
			(methodMap[method].(map[string]any))["parameters"] = params
		}
		endpoints[nk] = methodMap
	}
	pathData["paths"] = endpoints
	return pathData
}

func writeMapToFile(filename string, data map[string]any) {
	bytes, err := json.MarshalIndent(data, "", "\t")
	if err != nil {
		log.Fatal(err)
	}
	err = os.WriteFile(filename, bytes, 0666)
	if err != nil {
		log.Fatal(err)
	}
}

func main() {
	var err error
	root := "../../"
	if len(os.Args) > 1 {
		root = os.Args[1]
	}
	err = os.Chdir(root)
	if err != nil {
		log.Fatal(err)
	}

	pathData := generatePaths(".")
	out := "./templates/swagger/v1_groups.json"
	writeMapToFile(out, pathData)
}

the makefile would then need to be updated like so:

diff --git a/Makefile b/Makefile
--- a/Makefile	(revision 832a119c4fbb7ff5a0ee2c3b3e6a99ab5de4e71e)
+++ b/Makefile	(date 1755718162495)
@@ -169,6 +169,7 @@
 
 SWAGGER_SPEC := templates/swagger/v1_json.tmpl
 SWAGGER_SPEC_INPUT := templates/swagger/v1_input.json
+SWAGGER_SPEC_GROUP_INPUT := templates/swagger/v1_groups.json
 SWAGGER_EXCLUDE := code.gitea.io/sdk
 
 TEST_MYSQL_HOST ?= mysql:3306
@@ -287,6 +288,8 @@
 
 $(SWAGGER_SPEC): $(GO_SOURCES) $(SWAGGER_SPEC_INPUT)
 	$(GO) run $(SWAGGER_PACKAGE) generate spec --exclude "$(SWAGGER_EXCLUDE)" --input "$(SWAGGER_SPEC_INPUT)" --output './$(SWAGGER_SPEC)'
+	$(GO) generate -v ./build_tools/...
+	$(GO) run $(SWAGGER_PACKAGE) mixin -o './$(SWAGGER_SPEC)' $(SWAGGER_SPEC) $(SWAGGER_SPEC_GROUP_INPUT)
 
 .PHONY: swagger-check
 swagger-check: generate-swagger

@GamerGirlandCo commented on GitHub (Aug 22, 2025): > I think `make generate-swagger` can already do that? i did a ton of research and it can't, not without duplicating `//swagger:operation` comments for every API endpoint that starts with `/repos/{owner}/{repo}`. i wrote a small tool to automate this, meant to be run during the `make generate-swagger` target: `build_tools/swagger/main.go` ```go //go:generate go run main.go ../../ package main import ( "encoding/json" "log" "os" "path/filepath" "regexp" ) var rxPath = regexp.MustCompile("(?m)^(/repos/\\{owner})/(\\{repo})") func generatePaths(root string) map[string]any { pathData := make(map[string]any) endpoints := make(map[string]any) fileToRead, err := filepath.Rel(root, "./templates/swagger/v1_json.tmpl") if err != nil { log.Fatal(err) } swaggerBytes, err := os.ReadFile(fileToRead) if err != nil { log.Fatal(err) } raw := make(map[string]any) err = json.Unmarshal(swaggerBytes, &raw) if err != nil { log.Fatal(err) } paths := raw["paths"].(map[string]any) for k, v := range paths { if !rxPath.MatchString(k) { // skip if this endpoint does not start with `/repos/{owner}/{repo}` continue } // generate new endpoint path with `/group/{group_id}` in between the `owner` and `repo` params nk := rxPath.ReplaceAllString(k, "$1/group/{group_id}/$2") methodMap := v.(map[string]any) for method, methodSpec := range methodMap { specMap := methodSpec.(map[string]any) params := specMap["parameters"].([]any) params = append(params, map[string]any{ "description": "group ID of the repo", "name": "group_id", "type": "integer", "format": "int64", "required": true, "in": "path", }) // i believe for...range loops create copies of each item that's iterated over, // so we need to take extra care to ensure we're mutating the original map entry (methodMap[method].(map[string]any))["parameters"] = params } endpoints[nk] = methodMap } pathData["paths"] = endpoints return pathData } func writeMapToFile(filename string, data map[string]any) { bytes, err := json.MarshalIndent(data, "", "\t") if err != nil { log.Fatal(err) } err = os.WriteFile(filename, bytes, 0666) if err != nil { log.Fatal(err) } } func main() { var err error root := "../../" if len(os.Args) > 1 { root = os.Args[1] } err = os.Chdir(root) if err != nil { log.Fatal(err) } pathData := generatePaths(".") out := "./templates/swagger/v1_groups.json" writeMapToFile(out, pathData) } ``` the makefile would then need to be updated like so: ```diff diff --git a/Makefile b/Makefile --- a/Makefile (revision 832a119c4fbb7ff5a0ee2c3b3e6a99ab5de4e71e) +++ b/Makefile (date 1755718162495) @@ -169,6 +169,7 @@ SWAGGER_SPEC := templates/swagger/v1_json.tmpl SWAGGER_SPEC_INPUT := templates/swagger/v1_input.json +SWAGGER_SPEC_GROUP_INPUT := templates/swagger/v1_groups.json SWAGGER_EXCLUDE := code.gitea.io/sdk TEST_MYSQL_HOST ?= mysql:3306 @@ -287,6 +288,8 @@ $(SWAGGER_SPEC): $(GO_SOURCES) $(SWAGGER_SPEC_INPUT) $(GO) run $(SWAGGER_PACKAGE) generate spec --exclude "$(SWAGGER_EXCLUDE)" --input "$(SWAGGER_SPEC_INPUT)" --output './$(SWAGGER_SPEC)' + $(GO) generate -v ./build_tools/... + $(GO) run $(SWAGGER_PACKAGE) mixin -o './$(SWAGGER_SPEC)' $(SWAGGER_SPEC) $(SWAGGER_SPEC_GROUP_INPUT) .PHONY: swagger-check swagger-check: generate-swagger ```

GiteaMirror commented