Repository navigation
Add support for updating gradle wrapper #2223
Description
Activity
Thanks for the kind words @rahulsom!
Looking through these docs it does look like it would be pretty straightforward for Dependabot to update Gradle wrapper versions. I'm not going to add it straight away (I'm swamped with a few other updates) but I'll leave this open and come back to it.
Reacted by Rahul Somasunderam, Klara, Kirill Merkushev, Kavin, Petr Portnov | PROgrm_JARvis, James, Oliver Weiler, FunkyMuse, IsakTheHacker and slPerryRhodanReacted by HerrDerbThis would be awesome!
Hi @greysteil! Any chance to prioritize this?
At the moment I'm afraid we have more than we can handle just integrating with GitHub. We'd love to get to this, but unless it's an open source contribution it's going to take some time.
@greysteil do you have pointers where and how it needs to be implemented? I could take a look into it.
@feelepxyz maybe you have some pointers?
Any progress on this?
@infin8x I don't need a commitment, just a pointer where I should start looking. There is a lot of code and I don't have time either, so if I spend time helping you out then I want to do it as efficiently as possible. I think it would be enough, if you can point me to the file where the analysis for updates takes place. Thanks in advance
57 remaining items
@kbukum1 What about GitHub Enterprise Cloud with data residency, do you still need some flags or a new release? The dependabot run uses the latest
ghcr.io/dependabot/dependabot-updater-gradleimage but it does not create a Gradle wrapper PR.Let's wait on @kbukum1 / team. But we can probably tell from the logs in the meantime. What is the digest of
ghcr.io/dependabot/dependabot-updater-gradlethat is running in your environment?Also, for the flag, do you see the flag on in your logs? When the job runs, you should see
"gradle-wrapper-updater":trueunderJob definition:The feature is behind
gradle_wrapper_updaterfeature flag. Probably it has to be enabled for you as well.This seems to be enabled globally right now(if you create a new repo, it is ON) but it is possible that rollout in enterprise/other environments may be different. I believe that we may be able to send a change to remove the flag altogether at some point
What is the digest of ghcr.io/dependabot/dependabot-updater-gradle that is running in your environment?
Like I said, the latest one (at the time):
1dd17b7c49d7d8a1e1b3563fb8a96320223feb1byou should see "gradle-wrapper-updater":true under Job definition:
Nope, that property is not part of the job definition.
What is the digest of ghcr.io/dependabot/dependabot-updater-gradle that is running in your environment?
Like I said, the latest one (at the time):
1dd17b7c49d7d8a1e1b3563fb8a96320223feb1bI am sorry, I missed that in the discussion. That looks like a tag tough, not a digest (or at least, it does not resolve from my side)
That tag is currently pointing to
v0.359.0which is the latest and includes the changes.Nope, that property is not part of the job definition.
Then, that explains it. Although it is currently in "global rollout" it still needs the flag. it may be different for that environment where you run and we need to wait for the Dependabot's team to confirm why is not enabled there yet
@kbukum1 What about GitHub Enterprise Cloud with data residency, do you still need some flags or a new release? The dependabot run uses the latest
ghcr.io/dependabot/dependabot-updater-gradleimage but it does not create a Gradle wrapper PR.For this currently it is behind feature flag. We need to make a plan to cleanup the feature flag and backport for Github Enterprise. I will let you know when we are doing that.
CC: @honeyankit
- Reacted by Yeikel Santana, Philip Wedemann and v-kbukum1
our teams on GHES are primarily using public registries
Thanks for the insights, if that's the current use base maybe it'll be fine to start without this.
I was coming from my own anecdotal experience. In our case, public access is a non-starter since we mirror all repositories, and I’d guess other orgs may have similar constraints. That said, we’re not officially using Dependabot yet(we use core) so maybe that's why we don't matter yet.
cc @marcindabrowski Could you share your thoughts here? Based on your recent activity, it looks like you might have more accurate context and/or a need for private registry support.
For GHES/Enterprise versions we are now working on plan to make the feature available. We will let you know when it is ready and for which GHES release it will be available.
Reacted by Philip Wedemann, Yeikel Santana, Leonhardt Koepsell and PedroThanks a lot for this long-awaited feature!
I just wish this was a separate ecosystem so I can put different labels for the wrapper update PRs. These are not the same kinds of updates (dependencies VS tooling).
I guess there might be a workaround by declaring the
gradleecosystem twice and ignoringgradle-wrapperon one side, and allowing onlygradle-wrapperon the other side, but that's pretty tedious.Thanks a lot for this long-awaited feature!
I just wish this was a separate ecosystem so I can put different labels for the wrapper update PRs. These are not the same kinds of updates (dependencies VS tooling).
I guess there might be a workaround by declaring the
gradleecosystem twice and ignoringgradle-wrapperon one side, and allowing onlygradle-wrapperon the other side, but that's pretty tedious.This is what I'd do
- Listen on pull requests from
dependabot[bot] - If the title contains
gradle-wrapper-> Add additional tags
This would not work for grouped updates but based on your description, it seems that you'd be treating it separately
The other alternative you have is to look at the updated files. All the gradle wrapper updates touch the same files
- Listen on pull requests from
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Hi!
This is an amazing way to manage dependencies.
It would be awesome if it could also send PRs for gradle wrapper updates.
Typically this involves
Some projects using maven also use a wrapper - https://github.com/takari/maven-wrapper but that can be a separate issue.