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

[gregjotau]

@kbukum1 @gmazzo this will start working "out of the box" with - package-ecosystem: "gradle"

right? So once merged we will start seeing gradle wrapper with our current dependabot config? (That would be great)

[gmazzo]

@kbukum1 @gmazzo this will start working "out of the box" with - package-ecosystem: "gradle"

right? So once merged we will start seeing gradle wrapper with our current dependabot config? (That would be great)

That's correct. The change is under a gradle_wrapper_updater so they can have a controlled rollout of the feature, but ideally it should be enabled by default eventually.

I don't know when this is going to be merged, it's depend on the maintainers to review/merge this

[kbukum1]

Sorry @gmazzo ,

I wasn't able to review that. I am adding that on my list. I will find time hopefully this week to review that as soon as possible.

[kbukum1]

@gmazzo ,

There were some issues. I updated your smoke test PR. Now trying to rerun pipeline. It seems like there are some lint errors. Can we fix them?

• https://github.com/dependabot/dependabot-core/actions/runs/17937421045/job/51006125193?pr=12891

[gmazzo]

@gmazzo ,

There were some issues. I updated your smoke test PR. Now trying to rerun pipeline. It seems like there are some lint errors. Can we fix them?

• https://github.com/dependabot/dependabot-core/actions/runs/17937421045/job/51006125193?pr=12891

Hi @kbukum1 ! I rebased the PRs and fixed the lint issues. Everything seems to be green now ;).

[gmazzo]

Hi @kbukum1, any feedback on this?

[gregjotau]

@kbukum1 I can send you $100 bucks if you get it merged this week 🤣 (if monetary compensation is needed)

[gmazzo]

Conflicts 🤦 Solved. Now let's hope for that review 🙏