gradle/wrapper-upgrade-gradle-plugin

Gradle plugin that detects and updates Gradle and Maven wrappers to the latest Gradle and Maven version.

wrapper-upgrade-gradle-plugin's Issues

PRs that would replace another PR are not automatically closed.

Given:

• An already existing bump wrapper PR from version 8.4 to 8.5
• A new bump wrapper PR got open from version 8.4 to 8.6

The first PR stay open and will not automatically closed (and the branch deleted).

I guess it would be nice if this is supported 🙃

Wrapper Upgrade Github Action

I would love to see a Github Action for upgrading Gradle Wrapper which is official maintained by Gradle. (like your wrapper-validation-action)
That would make the update process more efficient. :)

Delete the branch when PR is merged

Is it possible to somehow make the plugin delete the created branch when the PR gets merged? I have a suspicion that it can only be achieved with a GitHub App.

GHFileNotFoundException when trying to create PR

I've tried this out for updating wrappers in the junit5-samples repo via a separate repo:
https://github.com/junit-team/wrapper-upgrade

However, I'm getting the following error:
https://ge.junit.org/s/ldkbyuhdhqska/console-log

Do not run `wrapper` task in case there is no upgrade available

I noticed that this plugin will always running the wrapper tasks, regarding of if there is an upgrade available.
However, the plugin nows already if there is an upgrade available.

wrapper-upgrade-gradle-plugin/src/main/java/org/gradle/wrapperupgrade/UpgradeWrapper.java

Lines 243 to 251 in e60ef6b

	private static VersionInfo getLatestBuildToolVersion(BuildToolStrategy buildToolStrategy, boolean allowPreRelease, VersionInfo usedBuildToolVersion) throws IOException {
	VersionInfo latestBuildToolVersion = buildToolStrategy.lookupLatestVersion(allowPreRelease);
	if (VersionNumber.parse(usedBuildToolVersion.version)
	.compareTo(VersionNumber.parse(latestBuildToolVersion.version)) >= 0) {
	return usedBuildToolVersion;
	} else {
	return latestBuildToolVersion;
	}
	}

Here it checks for the current release. If there is no upgrade available, it just returns *the * version (that is, usedBuildToolVersion).

Then it will only use that version to run the wrapper task. Whether if it is the same version or not.

wrapper-upgrade-gradle-plugin/src/main/java/org/gradle/wrapperupgrade/UpgradeWrapper.java

Lines 63 to 65 in e60ef6b

	Params params = Params.create(upgrade, buildToolStrategy, allowPreRelease, layout.getProjectDirectory(), getCheckoutDir().get(), gitHub, execOperations);
	if (!prExists(params)) {
	createPrIfWrapperUpgradeAvailable(params);

wrapper-upgrade-gradle-plugin/src/main/java/org/gradle/wrapperupgrade/UpgradeWrapper.java

Lines 82 to 90 in e60ef6b

	private void createPrIfWrapperUpgradeAvailable(Params params) throws IOException {
	runWrapperWithLatestBuildToolVersion(params);
	createPrIfWrapperChanged(params);
	}
	private void runWrapperWithLatestBuildToolVersion(Params params) {
	buildToolStrategy.runWrapper(execOperations, params.rootProjectDir, params.latestBuildToolVersion);
	buildToolStrategy.runWrapper(execOperations, params.rootProjectDir, params.latestBuildToolVersion);
	}

I guess it makes sense to avoid this. It is an unnecessary waste of resources.
Especially since you also recommend running this periodically in the readme:

wrapper-upgrade-gradle-plugin/README.md

Line 97 in e60ef6b

Note that a check is done first to make sure the branch does not exist yet. That way you can run `upgradeGradleWrapperAll` and `upgradeMavenWrapperAll` periodically with a cron, CI job... a bit like dependabot does for upgrading libs.

In case there is no higher version than the current version, just skip the task execution and thats it 🤷

`register` does not work. But `create` works.

This is also in the readme:

wrapperUpgrade {
    gradle {
        register("some-gradle-project") {
            repo.set("my-org/some-gradle-project")
            baseBranch.set("release")
        }
        register("some-samples-gradle-project") {
            repo.set("my-org/some-samples-gradle-project")
            dir.set("samples")
        }
    }
}

But register will not work. It seems the plugin is too late to catch it.
However, create will work.

I'm not sure if this needs to be fixed in the plugin itself or in the readme 🤔

I also ask myself, why does this not matter in the Groovy version 🙃

Wrapper should not be updated if the project uses a later version

When a project uses a version of Gradle that's newer than the latest stable release, e.g. a release candidate, the plugin currently sends a PR. For example: junit-team/junit5#3359

Instead, it should only update the wrapper if the version used by the project is older than the version it's attempting to upgrade to.

Always sign off wrapper updates in the commit message

It is good practice to always signoff commits, especially in update bots like this. Dependabot already does it and it would be awesome to add this feature here also. Something like this but replaced with the actual name and email:

...
Signed-off-by: dependabot[bot] <[email protected]>

Note: There is a GitHub bot called DCO that checks PRs to see if the commits are correctly signed-off, that is what made me aware of this

Provide option to create one PR per repo

Running all wrapper updates against the JUnit 5 Samples repo yields 9 PRs. An option to create one PR per repo would make that easier to work with.

Wrapper upgrades PRs doesn't run any tests

See for example this PR:
#188

It checks only the DCO but don't execute other tests.

This is because the PR were created by an GH Action using the build in secrets.GITHUB_TOKEN.
See

wrapper-upgrade-gradle-plugin/.github/workflows/wrapper-upgrade-execution.yml

Line 15 in fa846e8

TOKEN: ${{ secrets.GITHUB_TOKEN }}

and

wrapper-upgrade-gradle-plugin/.github/workflows/wrapper-upgrade-execution.yml

Line 37 in fa846e8

WRAPPER_UPGRADE_GIT_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I guess it make sense that also the bump wrapper PRs run all of the existing tests.

To do this, one option is to provide another secret (from another user) and invite them to this repository as a collaborator with write access. Then using this secret inside the action.
The user will then create the pull requests, instead of the "GitHub Action Bot".

You might want to use your bot-githubaction user for that? 😁

PR text unclear when the Maven Wrapper updates

Today, I see PRs such as this one:

gradle/common-custom-user-data-maven-extension#223

The title of this PR, `Bump Maven Wrapper from 3.9.6 to 3.9.6 #223, is confusing since the version numbers are the same. It requires me to perform a deeper investigation to see that the Maven wrapper is updating rather than the Maven version.

It would be nice if instead the generated PR could be clear about what was updated.

Wrapper upgrades for the same repository should be batched in the same PR

Currently, when more than one Wrapper upgrade is performed for the same repository, there will be an equal number of PRs created for that repository.

For example: https://github.com/gradle/develocity-build-config-samples/pulls?q=is%3Apr+is%3Aclosed+%22Bump+Gradle+Wrapper+from+8.6+to+8.7%22

It would be nice if the plugin would batch all upgrades for the same repository and only create a single PR per repository.

Created tasks doesn't show up in `tasks` overview

When you run gradle tasks, only the aggregated tasks will show up:

This is because you don't set the group and description:

wrapper-upgrade-gradle-plugin/src/main/java/org/gradle/wrapperupgrade/WrapperUpgradePlugin.java

Line 28 in c99d412

TaskProvider<UpgradeWrapper> upgradeTask = project.getTasks().register("upgradeGradleWrapper" + taskNameSuffix, UpgradeWrapper.class, upgrade, BuildToolStrategy.GRADLE);

Maybe this is intended 🤷
But I think it make sense that you show all created tasks in the overview 🙃

Running locally produces "fatal: could not read Username"

Good work on this plugin! I'm just taking it for a spin...

When I setup the plugin in a project.

plugins {
    id 'base'
    id 'org.gradle.wrapper-upgrade' version '0.10.1'
}
wrapperUpgrade {
    gradle {
        'spring-boot-api-example' {
            repo = 'tkgregory/spring-boot-api-example'
            baseBranch = 'master'
        }
    }
}

And run on Ubuntu:

WRAPPER_UPGRADE_GIT_TOKEN=<my-secret-here> ./gradlew clean upgradeGradleWrapperAll --info --stacktrace

I get this error:

Starting process 'command 'git''. Working directory: /mnt/c/workspace/gradle-wrapper-update-example/build/git-clones/spring-boot-api-example Command: git push --quiet -u origin wrapperbot/spring-boot-api-example/gradle-wrapper-7.4.2
Successfully started process 'command 'git''
fatal: could not read Username for 'https://github.com/tkgregory/spring-boot-api-example.git': No such device or address

When I run git push myself from the directory and enter username/token combo it works as expected. I think the error is because Git doesn't know the username.

Should there be a way to specify username as well as token? 🤔

User can read release notes in the plugin portal

We should use the description field of the plugin declaration to specify release notes. Currently, it is always a static string.

The description field is shown on the plugin portal for each published version. Setting the description field to release notes means they can be seen directly in the plugin portal, rather than only on GitHub. This makes release notes and changes much more discoverable for users wanting to update.

An example of this can be seen on the plugin portal page for com.gradle.plugin-publish: https://plugins.gradle.org/plugin/com.gradle.plugin-publish

What permissions are required for the `WRAPPER_UPGRADE_GIT_TOKEN`

The Readme states:

create a pull request on Github, it requires a Github access token, passed with WRAPPER_UPGRADE_GIT_TOKEN environment variable.

As users don't want to give the token more permissions as needed it make sense to document which exact permissions are needed for the PAT (personal access token)

Add options to specify labels, reviewers and assignees to be associated with the created pull request

It would be very helpful to be able to specify labels, reviewers and assignees for the pull request that gets created by the gradle plugin.

Task configuration in `README` is missleading

Hello togehter 👋

in your readme you have the section "Task configuration":

IMHO this is a bit of missleading. As consumers don't get in touch with any task here, right?
Instead, they setup the plugin extension.
So it would be rather Extension configuration.
But I think this is also not good.
I thought more into the direction of Configure the plugin or just Configuration...

What do you think? 🤔