-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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(datasource/sbt-package): Fallbacks to maven when no sbt directory listing available #18590
fix(datasource/sbt-package): Fallbacks to maven when no sbt directory listing available #18590
Conversation
Tested in this repository before the changes: https://github.com/fernandomora/renovate-sbt-test https://app.renovatebot.com/dashboard#github/fernandomora/renovate-sbt-test/865267319
|
Tested in this repository: fernandomora/renovate-sbt-test Logs after the changes running it locally:
Successfully created PR: fernandomora/renovate-sbt-test#5 |
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.
LGTM, just one minor suggestion
6a5a917
to
07c2171
Compare
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.
waiting for @zharinov feedback
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.
🤷♂️
🎉 This PR is included in version 34.21.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Changes
Fallbacks sbt datasources to maven datasource (which fetches versions based in maven-metadata.xml) if directory listing first approach is not successful.
Context
#18589
Using sbt datasource is not compatible with any maven repository that does not allow listing organization folder contents
sbt datasource tries to list all organization packages for the given package inside the repository to look for available versions of the same package with different suffixes.
That approach is unsuitable in repositories that doesn't allow directory listing, and only suitable option I see would be to fallback to maven datasource that checks maven-metadata.xml file with available versions for same package.
Closes #18589
Documentation (please check one with an [x])
How I've tested my work (please tick one)
I have verified these changes via: