-
Notifications
You must be signed in to change notification settings - Fork 18
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
useGithubAPI().getVersions()
should not need auth
#35
Comments
We originally used tags, but you have to paginate all of the tags (because the order is alphabetical), which can be 20 pages. Without a token GitHub limit you to 10 requests a minute, so you still need a token. Also this only effects builds which most users will not do, so I feel requiring a token is acceptable. I would prefer not to need a token, I just don’t see how we can achieve this. |
With the GitHub tags API, I don't see any option for pagination. I'm pretty sure the |
Last time I was in here Certainly if we can do it without auth I'm all for it. I just don't think we can based on last time I tried. |
I believe you're referring to the Given that I literally cannot find documentation on |
oh interesting, nice find! So I’m cool with Rationale: we only use this for builds currently, and making this change additive is safe. |
One possible additional caveat is that a single package build might require more than 10 other packages be queried, which is likely to still hit the request limit of the API, though that is a less common failure case. |
In fact we now iterate all tags since we can't guarantee anything about date order and semver order. |
Motivation
According to the comments on the getVersion method:
Why don't we just use the GitHub tags API and sort the tags according to semver? This should work for a majority of cases, and we can always be more clever if we need to.
I've written of proof of concept. It looks super ugly but it seems to work okay for the repos I have tested
This also has the added advantage (in my opinion) of actually sorting by semver. If I understand the current code setup correctly, this is not being done. This means that on the golang repo in the current implementation, the versions would look like:
which in my opinion is very unintuitive.
If there is no interest, feel free to close.
Tests
On this repo, it returns this which looks perfect
On the golang repo, which is just super problematic, it looks like this (which is okay, we could probably do some smarter parsing):
The text was updated successfully, but these errors were encountered: