Gitea: [Bug] [API] make pagination optional for GET /api/user/repos

Created on 8 Jun 2020  路  18Comments  路  Source: go-gitea/gitea

come up with #9452 in v1.12
ref https://github.com/go-gitea/gitea/pull/9452#issuecomment-640319866

prioritcritical

Most helpful comment

@CirnoT yeah but we can not just break drone integration. We can add deprecation notice and ask for drone developers to use paging and later in next version drop that. I think drone integration is used quite extensively to just break it

All 18 comments

Disagree, the mentioned comment clearly points at issue in Drone implementation which is missing pagination enumeration. We don't explicitly require pagination options to be set and with or without we need some sane limit on what we return. The instance might have 10 repos or it might have 2000 repos.

I'd like to have both

-> I'll take the gitea part

We definitely should NOT return all repos on API, instances can be small or can be huge.

This is not a bug but breaking change on our part since we added pagination; tools should now be updated to use it properly.

@CirnoT yeah but we can not just break drone integration. We can add deprecation notice and ask for drone developers to use paging and later in next version drop that. I think drone integration is used quite extensively to just break it

@lafriks the recent PR by @CirnoT provides a good way forward as it relies on app.ini setting for default response size, as if we don't have pagination then users with many repos could DOS themselves and run out of memory.

-> #11808

and for the DOS at witch point it get critical, we could add a hardcoded lim at 50/100/200 ...

sadly I dont know how to "depricate" a optional value to be required ...

think the best way is just inform huge project that they have to implement paggination for v1.13 now and switch in v1.13 ?

#11805 ...

@techknowlogick Yes but currently we do return all repos in versions <=v1.11

I think 30 is a sane default till a fix is pushed to go-scm for pagination support. People that can not update Drone for some reason will be able to adjust the default and max limits to their needs.

At my company git I have about 100 repos so that will break drone integration for me ;)

And as not everyone read changelog it will make a lot users not knowing why repos is not syncing anymore in drone and most probably they will complain to drone devs

To give a point it is already creating confusion, see article comment: https://dev.to/ruanbekker/self-hosted-cicd-with-gitea-and-drone-ci-200l

@lafriks with @CirnoT's PR you can change settings to increase value to 100 so that all your repos show up. All we can do is to put out the correct information, and send corrections to articles we see wrong. There are so many Gitea articles that say to wget version 1.2 of Gitea 馃槵

I know that and I will do that but for many this will cause confusion, someone should really send PR to fix drone/gitea integration before we release 1.12

Are the drone developers even aware of this ongoing discussion? I too feel like deprecation first and removal later is the right approach. Maybe allow turning off compat for deprecated features in config?

@ptman there is already PR that will fix drone support so that no changes in drone are needed

Was this page helpful?
0 / 5 - 0 ratings