Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GITEA] add new gitea service (release/languages) #9781
[GITEA] add new gitea service (release/languages) #9781
Changes from 10 commits
41b7368
a931179
2e28154
7963e26
2897abc
e122619
bfc73e8
1af4585
1a71bde
9494df1
441f2ba
dc113e0
c39884b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I have not had a really detailed look at this pagination code, but I'm not sure this is going to work.
If we look at
https://docs.gitea.com/next/development/api-usage
(which I think is relevant)
says to me that
a) The default max allowable value of
requestLimit
for a gitea server is 50b) This is a number that is going to be different for different gitea servers, so we can't safely assume its value
so I think trying to assume we can work out the number of pages up-front based on our hard-coded value of
requestLimit
and the total number of items feels like it is logic based on a bad assumption.Tbh, the way we do this for the GitHub badges is we just request the first page of releases ordered by date, and if you want the latest semver then the 'search space' for that is the first page of results, mostly for performance reasons. We've yet to have anyone pop up whose latest release by semver isn't in the first page of results.
Tbh, I'd be happy with that solution here too. When I flagged that
fetchPage
was unused code, I assumed we'd probably just delete it.Given we have to deal with multiple different implementations, if we do want to try and implement pagination like this, we'd need to infer the page size rather than assuming it up-front, but as I say, I'd also be happy to just gloss over it if we can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have MAX_RESPONSE_ITEMS for the absolute maximum, and DEFAULT_PAGING_NUM for the default pagination value which can be different per every instance. We do get a header for
x-total-count
for how many items are available, and if this is greater than the number of items in the array we could calculate the pages.When I found the pagination was not working in Gitlab's code too I thought to myself... who even has more than 100 releases to even scan through to find the latest SemVer! Happy to put this back and just assume the first page too.