Added Gradle Wrapper support

[gmazzo]

What are you trying to accomplish?

Introduces Gradle Wrapper bump support for gradle manager

Closes #2223 (issue open since 2018)

Smoke Tests PR: dependabot/smoke-tests#325
GitHub Docs PR: github/docs#39954

Anything you want to highlight for special attention from reviewers?

Following the same pattern used by gradle/libs.version.toml file, we'll only look (and support) for a gradle/wrapper/gradle-wrapper.properties in the root of the project.

distributionSha256Sum is also supported, and it will only be updated if the original properties file has the property.

Note

To minimize the risk of the feature and the impact on other smoke tests, I've introduced a new gradle_wrapper_updater feature flag for this change.

JAR binary and script files support

Updating other the gradle-wrapper.jar or the companion shell scripts is done through the new WrapperUpdater helper by leveraging the existing LockfileUpdater.
Most of its code was extracted into a new GradleUpdaterBase class, which has two abstract methods:

• target_file? to tell the given file is meant to be updated by it
• command_args to collaborate with the final gradle command run

Now both LockfileUpdater and the new WrapperUpdater inherit from GradleUpdaterBase.

Note

The update will not attempt to use any configuration for the wrapper task in the main build script; many of the repos will be broken because they rely on other files or included builds that will take a long time to complete. We limit to copying the wrapper-related files and running a clean, empty build.

How will you know you've accomplished your goal?

Running against a sample repo:

bin/docker-dev-shell gradle --rebuild
$ bin/dry-run.rb gradle gmazzo/gradle-codeowners-plugin

produces the desired diff:

 => bump gradle-wrapper from 8.14.3 to 9.0.0

    ± gradle/wrapper/gradle-wrapper.properties
    ~~~
    --- /tmp/original20250820-3941-jbt37h       2025-08-20 12:30:57.699516752 +0000
    +++ /tmp/updated20250820-3941-peq4i4        2025-08-20 12:30:57.700516752 +0000
    @@ -1,7 +1,7 @@
     distributionBase=GRADLE_USER_HOME
     distributionPath=wrapper/dists
    -distributionSha256Sum=bd71102213493060956ec229d946beee57158dbd89d0e62b91bca0fa2c5f3531
    -distributionUrl=https\://services.gradle.org/distributions/gradle-8.14.3-bin.zip
    +distributionSha256Sum=8fad3d78296ca518113f3d29016617c7f9367dc005f932bd9d93bf45ba46072b
    +distributionUrl=https\://services.gradle.org/distributions/gradle-9.0.0-bin.zip
     networkTimeout=10000
     validateDistributionUrl=true
     zipStoreBase=GRADLE_USER_HOME
    ~~~
    3 insertions (+), 3 deletions (-)

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

Important

Do not squash this PR, so we won't the history of lockfile_updater.rb being renamed to gradle_updater_base.rb and to attribute the original code to its autor.

[yeikel]

Can we detect this from the gradle-wrapper.properties?

In my current configuration, for example, this is pointing to a custom proxy. Example

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https://example.com/gradle-distributions/gradle-9.0.0-bin.zip
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionBuildTime=20250731163512+0000

[gmazzo]

This is pretty much intentional, because:

• The PR is aiming to support the 95% of the cases (if not more) where people use a standard Gradle distribution
• Even if I manage to infer the base URL for a non standard distribution, there won't be any guarantee that in that same server will exist an equivalent listing endpoint https://services.gradle.org/versions/all, or it will honor it's contact

Therefore the extra complexity to support this edge case won't pay off, at least in the scope of this PR

[yeikel]

That's understandable, but one of the core features of dependabot is the support for private registries, we may need to take that into account

[yeikel]

Thank you for making this change. It would be a great addition!

A few additional points regarding the review:

A key aspect of full Gradle wrapper support is regenerating the wrapper scripts (like gradlew and related files). If only the property file is updated and the scripts aren’t regenerated, it could cause issues.

In my view, a proper Gradle Wrapper upgrade should:

• Update the distribution property file
• Use the native Gradle binary to regenerate the wrapper scripts
• Commit both changes

For reference, see how the Update Gradle Wrapper Action handles this process.

As a side note, considering recent moves to separate ecosystems (such as npm and bum), it might be worth discussing if this should become its own ecosystem. I understand that gradle and the wrapper are related, but the structure and goal are different. Ultimately, however, it will be matter of opinion

I’ll leave that decision to the Dependabot team, as there are both advantages and disadvantages.

[gmazzo]

Thank you for making this change. It would be a great addition!

A few additional points regarding the review:

A key aspect of full Gradle wrapper support is regenerating the wrapper scripts (like gradlew and related files). If only the property file is updated and the scripts aren’t regenerated, it could cause issues.

In my view, a proper Gradle Wrapper upgrade should:

• Update the distribution property file
• Use the native Gradle binary to regenerate the wrapper scripts
• Commit both changes

For reference, see how the Update Gradle Wrapper Action handles this process.

As a side note, considering recent moves to separate ecosystems (such as npm and bum), it might be worth discussing if this should become its own ecosystem. I understand that gradle and the wrapper are related, but the structure and goal are different. Ultimately, however, it will be matter of opinion

I’ll leave that decision to the Dependabot team, as there are both advantages and disadvantages.

Thanks for the review @yeikel !

Let's wait for the maintainers feedback, but IMHO updating the whole set of scripts as that action does is just against the spirit of the tool itself. Not to mention it will be a technical challenge (or a blocker) to implement properly.

I dig into this tool a few days ago, so I'm not an expert at all. But based on what I get from experience, it works with a "token replacement" approach.

Implementing a proper script updating will require either to run Gradle or to do reverse engineering to the wrapper to mimic its behavior. That's just not the way this tool seems to work.

If a full update is required/desired, there are others tools for that or you can just do it manually yourself.

There better "Gradle-native" approaches to update dependencies that does not has the flaws the Dependabot has. This tool just provides a static fast approach that fits in the 90% of the cases (again or even more). The wrapper updater just falls under the same pattern IMHO

If only the property file is updated and the scripts aren’t regenerated, it could cause issues.

In my experience, this has never happened. The wrapper API has been pretty stable from Gradle earlier versions

it might be worth discussing if this should become its own ecosystem.

Well, IMHO I disagree. That Gradle has a different set of things to update, does not implies they are different ecosystems. If your thoughts are based on the Renovate approach, I'm not sure why it was implemented like that, but high-level, Gradle is just one. Its wrapper is just another kind of updatable component.

[yeikel]

Let's wait for the maintainers feedback, but IMHO updating the whole set of scripts as that action does is just against the spirit of the tool itself. Not to mention it will be a technical challenge (or a blocker) to implement properly.

I dig into this tool a few days ago, so I'm not an expert at all. But based on what I get from experience, it works with a "token replacement" approach.

If a full update is required/desired, there are others tools for that or you can just do it manually yourself.

There better "Gradle-native" approaches to update dependencies that does not has the flaws the Dependabot has. This tool just provides a static fast approach that fits in the 90% of the cases (again or even more). The wrapper updater just falls under the same pattern IMHO

If only the property file is updated and the scripts aren’t regenerated, it could cause issues.

In my experience, this has never happened. The wrapper API has been pretty stable from Gradle earlier versions

I appreciate your perspective, though I see things a bit differently. Dependabot aims to align closely with native tools, which is why there’s a growing focus on integrating with each ecosystem’s native tooling, for example, regenerating lock files or running mvn commands to get additional insights from maven directly.

The wrapper-related files are part of the wrapper distribution, which is why the official documentation recommends using Gradle to update the wrapper.

Dependabot should aim to create pull requests that are ready for immediate merging, without requiring manual intervention to finalize them. In this case, that'd would include all the related files to the wrapper

Implementing a proper script updating will require either to run Gradle or to do reverse engineering to the wrapper to mimic its behavior. That's just not the way this tool seems to work.

Yes, I'd think we should run gradle to execute the upgrade after we identify the version we are trying to upgrade to.

From the docs:

       ./gradlew wrapper --gradle-version {gradleVersion}

In my experience, this has never happened. The wrapper API has been pretty stable from Gradle earlier versions

Your experience may be limited to specific cases, but Gradle often makes changes for important reasons, such as updating the binary, improving Java version detection, or other enhancements. These updates go beyond simply keeping the wrapper functional; they are all part of the same distribution, and ensuring alignment across these components is essential. Keeping them out of sync may introduce issues that are hard to troubleshoot

That said, the Dependabot team may welcome this initial version and use it to gather feedback. I would be among the first to raise an issue to ensure these files are generated for a more complete release. It doesn’t need to be included in the first iteration; we can release now and improve it over time. That's also a valid strategy

it might be worth discussing if this should become its own ecosystem.

Well, IMHO I disagree. That Gradle has a different set of things to update, does not implies they are different ecosystems. If your thoughts are based on the Renovate approach, I'm not sure why it was implemented like that, but high-level, Gradle is just one. Its wrapper is just another kind of updatable component.

Although this is a subjective view, I believe there is a meaningful separation between the Gradle wrapper and application library dependencies. The wrapper and libraries follow different lifecycles: their versions are managed and detected in distinct ways, updated through separate processes, and the wrapper does not interact with registries or dependency resolution like application libraries do.

Still, both are important parts of the Gradle ecosystem as you mentioned, and there are reasonable arguments for treating them together or separately depending on the situation. Ultimately, there are advantages and disadvantages to both approaches, and your perspective is valid as well

[gmazzo]

regenerating lock files or running mvn commands to get additional insights from the Maven directly.

Thanks for pointing that out, @yeikel. I just noted there are effective piece of code that run native tools, like mvn

I was originally reluctant to propose a solution like that, because running gradle requires having java installed as well. Which, at this point I'd assume it does if it's running maven.

Now I think a complementary step may be added to use ./gradlew wrapper task instead, falling back to this original approach if it fails.

Let me see what I can do, or it can be done in a follow-up PR too. I'd like to get feedback from the maintainers about this as well.

[yeikel]

I was originally reluctant to propose a solution like that, because running gradle requires having java installed as well. Which, at this point I'd assume it does if it's running maven.
Now I think a complementary step may be added to use ./gradlew wrapper task instead, falling back to this original approach if it fails.

The good news is that both Java and Gradle come pre-installed in the Gradle containers, so no fallback is required.

See

dependabot-core/gradle/Dockerfile

Lines 4 to 25 in 7da4bdd

	RUN apt-get update && apt-get install -y --no-install-recommends \
	openjdk-21-jdk \
	ca-certificates-java \
	wget \
	&& rm -rf /var/lib/apt/lists/*
	# Install Gradle
	ENV GRADLE_HOME=/opt/gradle
	ENV GRADLE_VERSION=8.14.2
	ARG GRADLE_DOWNLOAD_SHA256=7197a12f450794931532469d4ff21a59ea2c1cd59a3ec3f89c035c3c420a6999
	RUN set -o errexit -o nounset \
	&& echo "Downloading Gradle" \
	&& wget --no-verbose --output-document=gradle.zip "https://services.gradle.org/distributions/gradle-${GRADLE_VERSION}-bin.zip" \
	\
	&& echo "Checking Gradle download hash" \
	&& echo "${GRADLE_DOWNLOAD_SHA256} *gradle.zip" | sha256sum -c - \
	\
	&& echo "Installing Gradle" \
	&& unzip gradle.zip \
	&& rm gradle.zip \
	&& mv "gradle-${GRADLE_VERSION}" "${GRADLE_HOME}/" \
	&& ln -s "${GRADLE_HOME}/bin/gradle" /usr/bin/gradle

[gmazzo]

Hi @yeikel, I managed to get that to work, but in a complementary PR #12908 (since it involves more changes and a refactor of the gradle.lockfile feature)

Let's say if this one gets reviewed by Dependabot team soon 🙏

[yeikel]

Hi @yeikel, I managed to get that to work, but in a complementary PR #12908 (since it involves more changes and a refactor of the gradle.lockfile feature)

Let's say if this one gets reviewed by Dependabot team soon 🙏

Awesome, thank you!

I think that before this is reviewed, you should make sure that all the tests are passing as that'll be the first feedback you'll get 🙏

As of right now, the e2e smoke tests are failing

[gmazzo]

you should make sure that all the tests are passing as that'll be the first feedback you'll get 🙏

I coudn't find documentation on how to work with the smoke tests. They are in a different repo. I have a PR for them as well, but changing SMOKE_TEST_BRANCH does not feel correct either 🤔

Edit:
I just made changes to the smoke.yml workflow

[gmazzo]

I will try to check that hopefully tomorrow or early next week.

Thanks @kbukum1!

Assuming it's some kind whitelisting security check, make sure to also allow changes not just in gradle-wrapper.properties but also in gradle-wrapper.jar, gradelw and gradlew.bat files. In the JSON I shared, there are only changes for the .properties file

[yeikel]

t I couldn't find anything on from where it comes

@gmazzo
I will try to check that hopefully tomorrow or early next week.

@kbukum1 Please enable the feature to the forked repos shared above so I can also test this 🙏

[kbukum1]

@yeikel ,

Successfully enabled gradle_wrapper_updater on yeikel/kafka-ui
Repository yeikel/testcontainers-java not found.
Successfully enabled gradle_wrapper_updater on yeikel/git-machete-intellij-plugin/tree/develop

[kbukum1]

@yeikel ,

Seems like you need to enable dependabot for https://github.com/yeikel/testcontainers-java

[yeikel]

https://github.com/yeikel/testcontainers-java

It should be enabled now. Sorry for the confusion!

[kbukum1]

https://github.com/yeikel/testcontainers-java

Successfully enabled gradle_wrapper_updater on yeikel/testcontainers-java

[yeikel]

In one of the repositories, I am seeing the following failure

2025/11/07 21:26:25 INFO <job_1146444339> Total execution time: 4.81 seconds
updater | Failed to update files: To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.14.2/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build
FAILURE: Build failed with an exception.

• What went wrong:
  Project directory 'dependabot_tmp_dir/gradle' is not part of the build defined by settings file 'dependabot_tmp_dir/settings.gradle'. If this is an unrelated build, it must have its own settings file.
• Try:

Run with --info or --debug option to get more log output.
Run with --scan to get full insights.

This seems to be a consequence of moving the build files around instead of running it from the root directly of the project. We'll have to find a workaround for that

Full logs: https://github.com/yeikel/kafka-ui/actions/runs/19181649304/job/54839606560

edit: it seems that despite this error, the pull requests are still created 🤔

[yeikel]

I am also seeing that other error you saw above

Dependabot encountered '1' error(s) during execution, please check the logs for more details.
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Dependencies failed to update |
+----------------+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------+
| Dependency | Error Type | Error Details |
+----------------+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------+
| gradle-wrapper | dependency_file_not_supported | { |
| | | "message": "{"errors":[{"status":400,"title":"Bad Request","detail":"The request contains invalid or unauthorized changes"}]}" |

[gmazzo]

FYI @kbukum1 @yeikel, I opened a new PR fixing a couple of issues (one critical) I noted from the tests runs:
#13501

[kbukum1]

Hi team, sorry for being late. Support Gradle Wrapper feature flag rolled out 100%. I am planing to monitor for the day. Let me know if you get any issue. Also I will update the documentation accordingly.

[Gamebuster19901]

Hi team, sorry for being late. Support Gradle Wrapper feature flag rolled out 100%. I am planing to monitor for the day. Let me know if you get any issue. Also I will update the documentation accordingly.

FIrst, I want to say I have been wanting this feature for a long time. However, I have a serious concern with how it's currently implemented.

Dependabot is performing a full gradle wrapper update, which is modifying:

• gradle-wrapper.properties
• gradle-wrapper.jar
• gradlew
• gradlew.bat

In many repositories, maintainers explicitly do not accept PRs that modify binary files. These changes are opaque in review and violate common security/contribution policies.

Additionally, updating gradle-wrapper.properties alone is sufficent. There is no need for dependabot to modify the other files (especially in ways that are unreviewable). The next time any gradle command is run, the wrapper scripts will automatically download and regenerate the correct binaries from the URL specified in that file.

In my specific case, there is no easy way for me to independently verify that the gradle-wrapper.jar file dependabot commits is exactly the artifact retrieved from the distribution URL in gradle-wrapper.properties. (see https://github.com/WilderForge/ExampleMod/pull/52/files/3460911b37f783b3419debe5ebe0420309ad5f4e)

If dependabot limited the change to just gradle-wrapper.properties, I could just do the following:

1. Review the one line change, and merge it
2. Run gradle locally (or in CI)
3. Commit the regenerated wrapper files myself

Unless I'm missing something, as it stands, this behavior forces me to block all gradle wrapper updates from dependabot, even though the version bumps themselves are desirable.

Is there (or will there be) a way to limit updates to gradle-wrapper.properties only?

[tbroyer]

@Gamebuster19901 Fwiw, the https://github.com/gradle/actions#the-wrapper-validation-action will verify the gradle-wrapper.jar for you.

[jameswald]

Dependabot is working exactly as it should for most Gradle projects. I want all those files updated automatically by a predictable process.

Many years ago I added setDistributionSha256Sum to the wrapper so you could set the expected hash with --gradle-distribution-sha256-sum <hash>. This command option could be provided by Dependabot during the wrapper update process to ensure the jar's integrity thereafter.

The hashes are published at https://gradle.org/release-checksums and can be easily fetched via the URL https://services.gradle.org/distributions/gradle-<version>-wrapper.jar.sha256 such as https://services.gradle.org/distributions/gradle-9.3.0-wrapper.jar.sha256.

The bash and bat files aren't binaries so you can review those as needed.

[yeikel]

Dependabot is working exactly as it should for most Gradle projects. I want all those files updated automatically by a predictable process.

Many years ago I added setDistributionSha256Sum to the wrapper so you could set the expected hash with --gradle-distribution-sha256-sum <hash>. This command option could be provided by Dependabot during the wrapper update process to ensure the jar's integrity thereafter.

The hashes are published at https://gradle.org/release-checksums and can be easily fetched via the URL https://services.gradle.org/distributions/gradle-<version>-wrapper.jar.sha256 such as https://services.gradle.org/distributions/gradle-9.3.0-wrapper.jar.sha256.

The bash and bat files aren't binaries so you can review those as needed.

Could you please log this as a separate feature request so it is tracked/discussed?

[Gamebuster19901]

Dependabot is working exactly as it should for most Gradle projects. I want all those files updated automatically by a predictable process.

I disagree. For my projects, I specifically don't want those files updated by anyone other than maintainers. It's just too risky. I self host all my CI, so I would still have to pull the (potentially malicious) commit onto my machine and verify the hash. If for some reason the file didn't match, then I would also have to purge it from the local repository history (and github, somehow?) as well.

The bash and bat files aren't binaries so you can review those as needed.

I’m not very familiar with bash or batch scripting, honestly I don’t feel confident reviewing these files for subtle changes. I treat those files the same way I treat binaries. I would much rather run the wrapper update directly on my machine so I know all the files and binaries came directly from an official source.

Basically my philosophy is that if it's coming directly from the official source, it's safe. If a binary is not coming directly from an official source, I treat it as unsafe.

I don’t want dependabot to act as a middleman for updating binaries. I just want it to update version numbers, and I'll retrieve the binaries myself. That’s how it works for every other dependency I’ve used, and I’d like the Gradle wrapper to follow the same model.

If changing the default behavior isn’t something you want to do, would you guys be open to adding a flag or configuration option to limit updates to gradle-wrapper.properties only? I’d be happy to file a feature request if that’s the preferred path.

[hfhbd]

@Gamebuster19901 that’s fine, but is is related to this feature? You don’t need to merge the PR but just use it as remainder to update Gradle by yourself. You can always force push the created PR. But anyway, the Gradle wrapper jars are signed via PGP, so you can check it.

[hfhbd]

Many years ago I added gradle/gradle#1777 to the wrapper so you could set the expected hash with --gradle-distribution-sha256-sum . This command option could be provided by Dependabot during the wrapper update process to ensure the jar's integrity thereafter.

Dependabot already sets the SHA checksum: https://github.com/hfhbd/kotlinx-uuid/pull/510/changes But it requires to use the feature first.

[jameswald]

Dependabot already sets the SHA checksum: https://github.com/hfhbd/kotlinx-uuid/pull/510/changes But it requires to use the feature first.

Awesome! That works for me then.

[antonmos]

I echo @Gamebuster19901's need to be able to disable the gradle wrapper updates.
In microservices architecture, we use shared conventions plugins, so there is no way to guarantee that they will not be broken by a gradle upgrade, because the tests in a given service repo may not cover all of the scenarios.

@Gamebuster19901 that’s fine, but is is related to this feature? You don’t need to merge the PR but just use it as remainder to update Gradle by yourself.

When the PRs are created automatically individual teams may merge them, and waste time on troubleshooting and reverting.

[yeikel]

Hi all,

Let's please move this discussion to the dedicated issue #2223