Support upgrading Gradle itself

[airsquared]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

Gradle projects store which version of Gradle to use in the /gradle/wrapper/gradle-wrapper.properties file, and frequently forget to upgrade it.

A gradle-wrapper.properties may have various entries in any order but only the distributionUrl entry is relevant to the versioning and looks something like this:

distributionUrl=https\://services.gradle.org/distributions/gradle-8.1-bin.zip

To upgrade the gradle version, you only need to update the string in between gradle- and -bin. For example to upgrade from Gradle 8.1 to 9.0.1 as above, the line needs to be changed to:

distributionUrl=https\://services.gradle.org/distributions/gradle-9.0.1-bin.zip

It may end in either "-bin" or "-all" depending on which kind of distribution the user picked, but doesn't make a difference for upgrading the version.

The latest release of Gradle can be obtained programmatically from Gradle's GitHub releases.

[jeffwidman]

Thanks for the detailed description.

Does native Gradle have a feature to update this line itself? Ie, if we leveraged more native Gradle tooling, would it make it easier to solve this as a byproduct?

• Fully Featured Gradle Support with the Gradle Tooling API #1164

An alternative approach that'd make it easy to solve this is probably:

• Add support for github release fetched from wget/curl in Dockerfiles #2483

[airsquared]

There is also a command to upgrade which does the same thing:

./gradlew wrapper --gradle-version=9.0.1

I'm not sure if this is also available with the tooling API, but that may complicate things more compared to just editing a string in the properties file.

[yeikel]

I think that this would be a "new ecosystem" as we would be entering the business of upgrading a different type of files (wrapper files)

[hfhbd]

See also: #2223

[Thunderforge]

Sometimes newer versions of a Gradle wrapper also make changes to the following files (which are used for downloading the wrapper executable):

• ./gradlew (shell script)
• ./gradlew.bat
• ./gradle/wrapper/gradle-wrapper.jar

We could naively edit the value in ./gradle/wrapper/gradle-wrapper.properties, but then these other files wouldn't be updated. Gradle commands will still work properly under the requested version, but these scripts that download the wrapper executable won't have the latest bug fixes and optimizations.

If we could run ./gradlew wrapper --gradle-version=9.0.1, that would be ideal since it would update all four files.

(Also as a personal thing, I would love it if it would also ensure that ./gradlew has chmod +x so that Mac and Linux users can use it even if a Windows user generated it, but that might be out of scope).

[joffrey-bion]

That would indeed be great! Note that the proposed command is not complete. It's often desirable to use the new version's checksum as well, which means providing the --gradle-distribution-sha256-sum option in addition to --gradle-version.

For more info about the possibilities for this, please have a look at this GitHub Action:
https://github.com/gradle-update/update-gradle-wrapper-action

Sometimes newer versions of a Gradle wrapper also make changes to the following files

Because of this, it's usually useful to run the ./gradlew wrapper command twice:

• the first time sets the version in the properties file, but is still doing this by running the old version of Gradle
• the second time, the actual new Gradle version is downloaded and run (because of the properties file update), so it updates the related wrapper scripts and jar files, which can be part of the same "update Gradle wrapper" PR

I think that this would be a "new ecosystem" as we would be entering the business of upgrading a different type of files (wrapper files)

I agree with this too!

Also as a personal thing, I would love it if it would also ensure that ./gradlew has chmod +x so that Mac and Linux users can use it even if a Windows user generated it, but that might be out of scope

That should just be done the first time you generate the files. Or if the first person committing gradlew forgot to do it, it's easily fixable by just running git update-index --chmod=+x gradlew and then committing and pushing the change (it also has to be done only once). I don't think there is any point in dependabot to handle one-time setups (the point is to maintain things up-to-date, not to preconfigure things). AFAIK, subsequently updating the wrapper normally should keep the executable flag so I don't think Dependabot would mess this up.

[MGaetan89]

There is also a command to upgrade which does the same thing:

./gradlew wrapper --gradle-version=9.0.1

I'm not sure if this is also available with the tooling API, but that may complicate things more compared to just editing a string in the properties file.

And since Gradle 8.1, it's possible to use a label, instead of a specific version, for example:

./gradlew wrapper --gradle-version latest

https://docs.gradle.org/8.1/release-notes.html#gradle-wrapper-introduces-labels-for-selecting-the-version

[huehnerlady]

IS there any update on this?