-
Notifications
You must be signed in to change notification settings - Fork 41
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
Script to automatically update all library versions #65
Comments
We could decide to do something with this: https://blog.bazel.build/2019/03/31/rules-jvm-external-maven.html. I'd like to figure out what it does with dependency conflicts first to make sure. Then we can install that with a private repository name and then wire up processors + exports manually |
@ronshapiro it has the resolution logic of Coursier. I can imagine instantiating a custom
And then downstream libraries will depend on Let me know if you have other questions or suggestions for rules_jvm_external. |
Another thing for us to consider is using the Google Cloud Platform Libraries BOM (Maven central, GitHub). It provides a set of libraries that have been statically checked for linkage errors. This could help us avoid errors like this one (fix) (and maybe there was another error that required this?). If I did my testing right, then the BOM doesn't yet cover everything that we'd like it to. But maybe we can help add some libraries, or at least we can use the BOM as our own starting point. [edit: The commands below are my attempt to generate a list of libraries that bazel-common includes but the BOM does not specify a version for -- neither explicitly (by listing them) nor implicitly (by listing a library that depends on them).]
|
I just saw 842dd97, which fixes a linkage error, fly by. (One thing worth noting from that is that some of the artifacts in our list are build tools, not "traditional dependencies" in the narrower sense. If we're lucky, we can easily find compatible versions of all those artifacts, build tools and "traditional dependencies" both. But if not, it would be sufficient to find a set of compatible versions for each individual tool (in addition, of course, to the set for all the "traditional dependencies").) |
Another linkage error fixed in 6db2b87. |
The even easier thing would be automatic updates, like we get from Dependabot for most of our repos. As of this writing, Dependabot doesn't support Bazel, but RenovateBot does. Note that RenovateBot does not yet support I see a smallish number of |
I suspect that this will essentially happen automatically if we switch to |
Similar to Maven commands like:
mvn versions:use-latest-versions
mvn versions:use-latest-releases
mvn versions:update-properties
And just to spam more keywords, here are some Maven commands that display updates but don't make the changes:
mvn versions:display-property-updates
mvn versions:display-dependency-updates
I poked around the web and found some a project for keeping Bazel deps up to date, but it has its own system that might not play well with
bazel-common
:https://github.com/johnynek/bazel-deps
I notice that it's mentioned in:
https://github.com/bazelbuild/BUILD_file_generator#third-party-maven-dependencies
The text was updated successfully, but these errors were encountered: