https://kotlinlang.org logo
Join Slack
Powered by
How can one keep their build.gradle.kts update to ...
# gradle
s
How can one keep their build.gradle.kts update to with latest library updates? dependentbot can't update it atm. Anyone get around this?
v
Besides that I generally dislike such update bots, I hear that Renovate is better and more capable than Dependabot. And then there are also Gradle plugins like Ben Manes' 
gradle-versions-plugin
and 
refreshVersions
.
e
Dependabot can update version catalogs
v
Noone mentioned version catalogs. :-D But so can the others which update versions.
e
yep. but it's nice to move the dependency versions to the version catalog regardless, and then you have a wider choice of tools
s
Thanks folks for the pointers! I appreciate it!
h
Besides version catalogs, dependabot (and renovate too) does not run the Gradle build and use the tooling api, but parse the build file using regex. As long as you use „normal“ dependency notation, both tools are able to create PRs. But as soon as using code for your dependencies, updating your deps is impossible.
e
even if they used the tooling API, that would only be useful for determining which dependencies are out of date, not updating them
v
It's not impossible, it's just those tools being unable to. The versions plugin can find any display any version update, no matter how it is defined or programmed. The 
refreshVersions
plugin can update any version in normal notation that is coming from a Maven repository but being a Gradle plugin also properly gets all dependency information.
e
even if your declarations are in "normal" notation, there can still be other contributions from 
resolutionStrategy.force
or metadata rules that are still too much for tooling to handle generally
but sure, it probably works 90% of the time. so does regex parsing
v
The plugins - or a tool using tooling api - should get the resolution result, so any influencing fact should usually be taken into account, shouldn't it?
e
for figuring out what the current dependencies are, yes. but figuring out what part of code to change in order to change the resolution result is potentially wading through the black hole of Turing complete computation
m
I find 
renovate
more efficient than 
dependabot
it has also dashboard and nice PR description for the version updates. It works well with gradle version catalogs like dependabot, renovate also supports updating the gradle-wrapper version too
r
I’ve had good success using version catalogs + nl.littlerobots.version.catalog.update (a gradle plugin). its one of the many plugins derived from Ben Manes’s versions. I’ve swapped a number of times over the years, but this has served me best at this time.
v
Did you try 
refreshVersions
? As long as you only use Maven repositories, it is great to update the versions as it is faster than the versions plugin and can give you all newer versions as comments. I usually use both, Ben Manes' plugin for checking what is outdated, 
refreshVersions
to update versions when I want to update them.
r
you know, its been a while so I should probably look at that again 🙂
e
personally I find the plugin-based approaches annoying because they need to be applied and run separately for each included build, whereas the ones that scan versions.toml directly just work
r
feel that. I don’t use included builds extensively, but where I’ve run into that problem I’ve done some task-chaining into the inner build so I can just run the relevant tasks and get it all done. Kind of depends on taste too. I bias toward solutions that I can run locally as well as in infrastructure, so being able to trigger it from a gradle command is appealing to me.
v
Same 🙂
In earlier versions 
refreshVersions
did not support version catalogs, but only their own properties file for versions. Didn't like it back then, but since it supports updating the standard version catalog file, I quite like it.
67 Views
Open in Slack
PreviousNext
Powered by