Gradle support for secondary versions.props file

[tpittmanVS]

In addition to the typical build.gradle file, we store version info in versions.props as described here https://github.com/palantir/gradle-consistent-versions. We need versions.props tracked and incremented in the same way as renovatebot does for build.gradle

Is this feature currently supported or in the product roadmap?

[rarkins]

I know we certainly don't support the versions.lock part, so the answer is probably No. Can you provide an example repository and elaborate on the requirements further? e.g. is this completely defined by the palantir plugin only or is that also leveraging some other plugins or Gradle concepts Eg for the lock file?

[tpittmanVS]

Hey Rhys, thanks for your quick response. I think this simple example captures our use case: https://github.com/palantir/conjure-java-example. I believe gradle substitutes values from top-level versions.props when evaluating build.gradle.

As far as implementation details, I'm not too sure as I'm new to Gradle. I know the whole consistent versions/versions.prop framework does use Gradle Constraints. So to my eye, Gradle and Gradle Wrapper (gradlew) seem to be the only dependencies, but I have never set it up personally

For your own information, we use this framework across all our repos, and no one in the market seems to support it (dependabot, renovatebot, snyk, etc). We are considering whether it might be worth it to submit a PR to implement this functionality ourselves

[viceice]

I think we should add a separate manager for handling that file, as it's easy to parse and update by renovate.
The only part we need todo is running gradle to update the lockfile. This manager can support lockfile only. 🙃

Maybe we can name it gradle-consistent-versions. I'm very interested in this, as it would make dependency updating for renovate and gradle very easy. 🎉

[github-actions]

Thank you for providing a reproduction! 🎉 🚀

The Renovate team will take a look at the reproduction repository. Once we confirm the provided repository reproduces the problem, the label will be changed to reproduction:confirmed.

[janhoy]

Any status on this? I plan to attempt making a new manager. It would need to

• Parse versions.props and versions.lock
• Filter versions.lock against versions.props, leaving only the entries that match at least one props line (may be wildcard expr), leaving our direct and not transitive dependencies.
• Parse versions and lookup upgrades
• The PR needs to be made against versions.props, and run gradlew —write-locks before committing

[viceice]

Any status on this? I plan to attempt making a new manager. It would need to

• Parse versions.props and versions.lock
• Filter versions.lock against versions.props, leaving only the entries that match at least one props line (may be wildcard expr), leaving our direct and not transitive dependencies.
• Parse versions and lookup upgrades
• The PR needs to be made against versions.props, and run gradlew —write-locks before committing

no new manager. should be implemented inside Gradle manager.

[viceice]

Blocked by

• feat(manager/gradle): rewrite and extend parser #18484

[janhoy]

Is this unblocked due to #18663 ?

[rarkins]

Yes no longer blocked

[janhoy]

Ok, I'm attempting a PR to add support for this plugin.

[janhoy]

I now have a working branchthat produces correct PRs for this plugin, see https://github.com/janhoy/gradle-consistent/pulls

I'll do some cleanups and publish a PR...

[janhoy]

Another semi-related question:

In one project that I plan to start using renovate with this feature, the automated PR validation process also includes validating SHA-sum and licenses for all dependencies, i.e. we "lock" not only the dependency version, but also the dependency JAR SHA-sum in the repository.

So when renovate opens a PR, it will patch versions.props, update versions.lock (through --write-locks), but we also need it to run an arbitrary gradle task to compute new checksums. I see from the docs that there is postUpgradeTasks for self-hosted instances of renovate, due to security reasons of course. We'd like to use the official version, but I cannot find a way to specify an additional gradle task to run as part of the pre-commit update.

Before I open a new feature request issue, I thought I'd discuss it in context here. I'm thinking there could be a way for a repo to specify in renovate.json an additional gradle task, e.g.

{
  "gradle": {
    "postUpgradeGradleTasks": ["task1", "task2"], 
    "postUpgradeFileFilters": ["shasums.txt"],
  }
}

Techinically we already run ./gradlew --write-locks or update-locks, so it could be appended to the same command, but would there be security concerns or other concerns? If you will consider it, I'll open a new issue for it.

[viceice]

yes, there is a concern, as the task can manipulate the git directory/ hooks or the shared cache folder. so we don't like to allow arbitrary commands.

[renovate-release]

🎉 This issue has been resolved in version 34.52.0 🎉

The release is available on:

• GitHub release
• 34.52.0

Your semantic-release bot 📦🚀