Renovate: Gradle wrapper upgrade should update more files

Created on 19 Apr 2019  Â·  9Comments  Â·  Source: renovatebot/renovate

What Renovate type are you using?
Renovate GitHub App

Describe the bug

The upgrade of gradle is incomplete. It only updates the version in gradle/wrapper/gradle-wrapper.properties (see for example https://github.com/Ninja-Squad/globe42/pull/663/files, which upgrades from 5.3.1 to 5.4).
However, if I do the upgrade manually by following the procedure documented in the Gradle release notes:

./gradlew wrapper --gradle-version=5.4

then not only this URL is changed, but the generated gradlew and gradlew.bat files, and the binary wrapper jar files are being modified. See https://github.com/Ninja-Squad/globe42/pull/665/files for the same upgrade doing it by applying the correct upgrade procedure.

Renovate should apply the correct procedure instead of just changing the version.

Expected behavior

I expect renovate to produce the same changes as if I executed

./gradlew wrapper --gradle-version=5.4
gradle priority-3-normal bug

Most helpful comment

Thanks. Sounds like we need to perform this command as an “artifacts” get like we do with lock files, checksums, etc.

All 9 comments

The difference seems to be:

  • comments (surely entirely optional, and were they really introduced in 5.4?)
  • duplicate/incorrect 64MB RAM limit

I’m not a Gradle user but neither of these seem to be a problem, so will wait to gather more opinions before making any changes.

There is also a difference in the binary jar file used to download the gradle distribution. Maybe it's unimportant, maybe it's a big security fix. And maybe future upgrades will introduce more important changes in the script files or elsewhere.

The fact that this specific upgrade only brings minor, maybe ignorable changes to the files is irrelevant: there is an official procedure to upgrade gradle, that is documented and does everything required to make sure everything is installed as expected, and renovate should follow this procedure instead of taking shortcuts. IMHO of course :-)

Besides, these comments contain copyright/licensing information. If gradle, an open source project that I happily benefit from, thinks this should be in the files that I redistribute in my own projects, then I should comply, IMHO.

  • Shouldn’t the copyright terms have been in your repo already?
  • Or was 5.4 the first release with them in or enforced?

when doing a gradle upgrade with the command above it can change up to 4 files

  • gradlew - linux command executable
  • gradlew.cmd - windows command executable
  • gradle-wrapper.properties - file with the desired version number of gradle
  • gradle-wrapper.jar - logic for downloading the new distribution

start scripts rarly contain changes which are important, but gradle-wrapper.jar may contain security and bugfixes which are important for the downloading of the dsitribution which will be used when building the project

Thanks. Sounds like we need to perform this command as an “artifacts” get like we do with lock files, checksums, etc.

Shouldn’t the copyright terms have been in your repo already?

I have used renovate for the last few gradle updates, but I used to do the upgrade by myself before, so maybe the copyright terms could have appeared before (if I hadn't used renovate), but they're recent.

@rarkins I can try to fix this issue. Can you assign it to me?

:tada: This issue has been resolved in version 19.192.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  Â·  3Comments

OmgImAlexis picture OmgImAlexis  Â·  4Comments

Flydiverny picture Flydiverny  Â·  4Comments

OmgImAlexis picture OmgImAlexis  Â·  4Comments

Arcanemagus picture Arcanemagus  Â·  4Comments