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

[6543]

come up with #9452 in v1.12
ref #9452 (comment)

[CirnoT]

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.

[6543]

I'd like to have both

[6543]

-> I'll take the gitea part

[CirnoT]

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.

[lafriks]

@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

[techknowlogick]

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

[6543]

-> #11808

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

[6543]

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 ?

[6543]

#11805 ...

[lafriks]

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

[CirnoT]

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.