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
feat(repology): Support all repositories of repology #7833
Conversation
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 provide a public test repo to review
There is only a php docker image update pr. 😏 |
Ahh sorry, you want me to run this PR against that repo? Can do that, will take a little because the devcontainer is really slow on my macbook (and that is after disabling the jest vscode extension which if enabled runs the test all the time and kills my computer :D). |
No hurry, that why I don't use the dev container. 😏 I'm using wsl2 remote development, as it's faster that on my default windows 10. 😁 I think you can run this on your local system, as for that test it only needs node to run. |
I've disabled the vscode jest extension, too annoying 😉 |
I do like the idea of the devcontainer though, especially when testing different managers besides nodes/npm. Today it did work perfectly. I replaced the log in the initial description with the new run against this test repo. |
If i need manager tools, i use |
🎉 This PR is included in version 23.90.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Context:
I was running into the issue that renovate-bot wasn't able to use the repository
homebrew_cask
from repology because it is not available in https://repology.org/tools/project-by. I was curios though why renovate-bot isn't using the normal API (which supports everything) and instead this helper tool. After looking through the code it didn't really make sense to use this tool, because all this tool does is a HTTP redirect to the API, so why no use it in the first place and save one redirect and as it turns out also one request to the API in some cases. After a successful local test (log attached) I though I might open a PR directly and not an issue.Changes:
The changes include:
https://repology.org/tools/project-by?name=pkgName
directly callhttps://repology.org/api/v1/project/pkgName
(which the first one redirectes to anyway)binname
andsrcname
directly afterwards if we still have more than one package. The tests also proved that this still works.Documentation (please check one with an [x])
How I've tested my work (please tick one)
I have verified these changes via:
Log of successful run with repo `homebrew_cask` (previously unsupported)