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
fix(repology): Correctly resolve packageName to repology project again #7997
Conversation
As a fallback now do the direct API call, but only if the repository is not supported by the resolver tool
What impact is this likely to have on API calls per package? And if there's a project-package mapping that needs to be discovered, can it be cached for a long period (longer than regular lookups)? |
It is now basically the same as before #7833. There is caching in place for each package, not sure though how long that caches. I guess its the default package cache? Additional caching could be added to store the package->project mapping, so when rechecking the version we would already know where to look(1 request). The invalidation might be a little more involved, as we need to do that if we cannot find the package in the project anymore or the project itself. If this is desired i wouldn't want to do it in this pr and rather spin up a second one afterwards. |
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.
Please do some real tests, I would like to see some sample pr's
Here is the sample repo: https://github.com/danez/repology-test/pulls Log
|
🎉 This PR is included in version 24.4.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Context:
#7979
Fixes #7988
First of all sorry that I broke this. In the last PR I completely missed that not ever package is represented as it's own project in repology but sometimes they are grouped together (like
gcc
project containspackagesgcc
,gcc-default
,gcc-docs
, ...)Now to fix this I had to bring back the usage of
https://repology.org/tools/project-by
because this tool can resolve a package-name to a project-name and then redirects to the correct API URL.If the request to this tool returns HTTP code 403, it means the repository (e.g.
homebrew_cask
) is not supported by this tool. In this case and only in this case we try to request the API with the package name as the project name. This won't work always but in some cases it might find the actual package.Changes:
https://repology.org/tools/project-by
first for binary packages then for source packages.Documentation (please check one with an [x])
How I've tested my work (please tick one)
I have verified these changes via: