Add pagination to list API endpoints that do not have it yet

[qwerty287]

• /repos/{owner}/{repo}/issues/{index}/labels
• /repos/{owner}/{repo}/issues/comments/{id}/reactions
• /repos/{owner}/{repo}/branch_protections
• /repos/{owner}/{repo}/contents
• /repos/{owner}/{repo}/git/refs
• /repos/{owner}/{repo}/git/refs/{ref}
• /repos/{owner}/{repo}/hooks/git
• /repos/{owner}/{repo}/issue_templates
• /repos/{owner}/{repo}/releases/{id}/assets
• /repos/{owner}/{repo}/reviewers
• /repos/{owner}/{repo}/teams
• /user/emails
• /users/{username}/heatmap
• https://codeberg.org/api/swagger#/issue/issueGetComments (add page and limit params)
• /repos/{owner}/{repo}/git/trees/{sha} (use limit param instead of per_page)

[qwerty287]

There is also one endpoints that only support since/before params, but not page/limit`:

https://codeberg.org/api/swagger#/issue/issueGetComments

[qwerty287]

And /repos/{owner}/{repo}/git/trees/{sha} uses per_page instead oft limit, should be deprecated.

[lunny]

And /repos/{owner}/{repo}/git/trees/{sha} uses per_page instead oft limit, should be deprecated.

I updated your issue so that we can follow them easier. :)

[ChristopherHX]

...3 Years later, I found this enhancement by searching for per_page after seeing an inconsistency about per_page and limit in the code

I would prefer that all gitea rest apis hide their acceptance of per_page, but do consistently accept it if no limit is in the query just for GitHub Rest Compatibility.

And /repos/{owner}/{repo}/git/trees/{sha} uses per_page instead oft limit, should be deprecated.

This still seems to be the case to not accept limit, if allowing per_page as fallback is acceptable for all paging apis I would try to fix this inconsistency.

e.g. I am implementing/testing this api of Gitea Actions https://github.com/kedacore/keda/blob/9b954d4430e2530cc4bb700528e148b6baac2de7/pkg/scalers/github_runner_scaler.go#L681

Uses per_page=100, which is the only accepted query parameter for pagesize on GitHub Rest api, ignoring per_page means running action runs in the past run 31 and for it's jobs are not noticed by the metric. Seems like this is to avoid rate limits of GitHub Rest by using the max pagesize and never requesting the second page (not relevant for Gitea itself). Cloning the GitHub implementation for Gitea to use limit as query parameter and allow more scopes would be possible, if I would write an integration test for keda, I guess