Fix: Gradle Wrapper native updated run for every dependency

[gmazzo]

What are you trying to accomplish?

Fix a couples of issues introduced after #12891:

• We are running the native WrapperUpdater for every dependency bump, not sure the Gradle Distributions ones, and with the wrong Gradle version (as the random dependency's version is picked). Examples: #1, #2
• Inverted the order of the LockfileUpdater and WrapperUpdater updaters: in the case we are bumping Gradle version, and the project does have .lockfiles, we want first to bump Gradle to pickup any possible change in the build logic or the content of the .lockfile, introduced by recent versions of Gradle.

Anything you want to highlight for special attention from reviewers?

The first issue is critical for a correct implementation. The second, desirable, since .lockfile feature is stable and are not tied to the Gradle version itself.

How will you know you've accomplished your goal?

Native updaters are not covered by unit tests. Since we have an open PR for adding a smoke tests for the Gradle Wrappers, we may consider this case in there as well by either:

• Adding a new gradle-wrapper-lockfile scenario (keeping gradle-lockfile and gradle-wrapper in isolation)
• Add .lockfiless to gradle-wrapper
• Add a gradle/gradle-wrapper.properties to gradle-lockfile

Let me know which one is better, in terms of isolation but also redundancy.

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.

[yeikel]

Thanks for the follow up fix. Could you please

• Update the pull request title with what's being fixed
• Add a test/Integration test that demonstrates the issue and proves the fix?

[kbukum1]

LGTM

[kbukum1]

Thanks for the follow up fix. Could you please

• Update the pull request title with what's being fixed
• Add a test/Integration test that demonstrates the issue and proves the fix?

@gmazzo , as @yeikel mentioned, can we also add/update the spec for the fix (empty dependencies)

[gmazzo]

Update the pull request title with what's being fixed

🤦 just didn't noted. Let me work on the tests then

can we also add/update the spec for the fix (empty dependencies)

Can you elaborate what "empty dependencies" mean? The test I had in mind was to somehow (need to research) mock the native runner, then duplicate any of the existing tests (not related to wrapper dependencies), enable the experiment, and assert the native runner is not called

[kbukum1]

Update the pull request title with what's being fixed

🤦 just didn't noted. Let me work on the tests then

can we also add/update the spec for the fix (empty dependencies)

Can you elaborate what "empty dependencies" mean? The test I had in mind was to somehow (need to research) mock the native runner, then duplicate any of the existing tests (not related to wrapper dependencies), enable the experiment, and assert the native runner is not called

I jjust meant empty dependencies according to your return [] empty array. I mean you only need to implement spec for the issue that happened. If the specs shows the issue is fixed properly we are good.

[kbukum1]

Update the pull request title with what's being fixed

🤦 just didn't noted. Let me work on the tests then

can we also add/update the spec for the fix (empty dependencies)

Can you elaborate what "empty dependencies" mean? The test I had in mind was to somehow (need to research) mock the native runner, then duplicate any of the existing tests (not related to wrapper dependencies), enable the experiment, and assert the native runner is not called

I jjust meant empty dependencies according to your return [] empty array. I mean you only need to implement spec for the issue that happened. If the specs shows the issue is fixed properly we are good.

It is ok to mock the native runner to return proper result (how normally native runner wil return) into spec related file and get proper output which was causing the issue before and use that to reproduce the new expected output properly in the and show in the spec that passes successfully then we are good.

[gmazzo]

Ok, just pushed the changes with the test scenarios.

First, I've enabled both experiments (the wrapper and lockfile) in the tests, to make sure native runners logic is allowed to run. And also, an allows clause for SharedHelpers that will throw if run_shell_command is ever called.
This will reveal the issue, but also protect us from any accidental change in the future for both native updaters.

By the way, LockfileUpdater seems not to be covered by tests, but that's is not scope of this PR.

Finally, in the wrapper test, I've relaxed the allows, to just do nothing. Later I assert it was called with the expected command.

You can verify the issue by running the test after commenting the line:
https://github.com/dependabot/dependabot-core/pull/13501/files#diff-25c6c1fa1ac7e0ccd7742c8143ec3bfead5f231bc84581ba1b01921c7ed212aaR43

Any feedback is welcome, not 100% it's a "good pattern" the one I applied.

[kbukum1]

Thanks @gmazzo , for the effort. @yeikel let me know if you have anything. I am going to deploy the changes and let you know when changes are merged. Then we can test it again.

[kbukum1]

@gmazzo , @yeikel ,

I just merged the changes. It will be great if you can test on your repositories accordingly we can discuss rolling out the feature flag.

[yeikel]

@gmazzo , @yeikel ,

I just merged the changes. It will be great if you can test on your repositories accordingly we can discuss rolling out the feature flag.

Thank you @gmazzo for the effort and @kbukum1 for reviewing it 🥇

@kbukum1 Did you update the service API to allow these new files? From what I re-tested the error still exists

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]

Same here.

I can confirm the fix was effective, since we run the native updated only once (when bumping the wrapper dependency):
https://github.com/gmazzo/gradle-codeowners-plugin/actions/runs/19278296391/job/55123354778#step:3:618

But the PR is still failing with the The request contains invalid or unauthorized changes:
https://github.com/gmazzo/gradle-codeowners-plugin/actions/runs/19278296391/job/55123354778#step:3:828

Two other PRs were successfully created (#1, #2):
https://github.com/gmazzo/gradle-codeowners-plugin/actions/runs/19278296391/job/55123354778#step:3:818

[kbukum1]

@gmazzo , @yeikel ,
I just merged the changes. It will be great if you can test on your repositories accordingly we can discuss rolling out the feature flag.

Thank you @gmazzo for the effort and @kbukum1 for reviewing it 🥇

@kbukum1 Did you update the service API to allow these new files? From what I re-tested the error still exists

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"}]}" |
| | | } |
+----------------+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------+

Thank you for checking. Yes, I think I missed that. I am going to update API to allow the files.

[kbukum1]

@gmazzo , @yeikel

I am allowing additionally to existing update followings files. After deploying the change, I will let you know.

          "gradlew",
          "gradlew.bat",
          "gradle/wrapper/gradle-wrapper.jar",
          "gradle/wrapper/gradle-wrapper.properties",
          "subproject/gradlew",
          "subproject/gradlew.bat",
          "subproject/gradle/wrapper/gradle-wrapper.jar",
          "subproject/gradle/wrapper/gradle-wrapper.properties",

[yeikel]

@kbukum1 I think that the following list should be enough

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

[gmazzo]

"subproject" is generic or literal? The logic (if I remember correctly) will pick up wrapper updates at root but also any included build. It would be nice if you white list those files at any directory, since we can't know in advance the structure of the project.

For those with that kind of complexity, the PR will still fail

[yeikel]

@kbukum1 Can the expression be a glob like this?

**/gradle-wrapper.jar
**/gradle-wrapper.properties
**/gradlew
**/gradlew.bat

By definition, the paths above are the paths that most builds will have, however, it is possible to have more complex builds like @gmazzo pointed out

[yeikel]

Here’s an example I was able to find: https://github.com/FunkyMuse/KAHelpers/tree/main/build-logic

@gmazzo, would the current logic actually scan build-logic to locate the wrapper? From what I can tell, it might not:

dependabot-core/gradle/lib/dependabot/gradle/file_fetcher.rb

Lines 27 to 32 in c883730

	SUPPORTED_WRAPPER_FILES_PATH = %w(
	gradlew
	gradlew.bat
	gradle/wrapper/gradle-wrapper.jar
	gradle/wrapper/gradle-wrapper.properties
	).freeze

I’ve forked the project here: https://github.com/yeikel/KAHelpers so we can run some tests as needed

To be fair, I haven’t seen this pattern often. I struggled to find more examples here in github.com

We might be fine shipping it, cover roughly 90% of use cases, and gather feedback from there if any. Gradle supports tons of customization features and unless we parse the build (#1164), we may not be able to cover every single use case/customization

[kbukum1]

@gmazzo , @yeikel since currently gradle wrapper update works, what do you think about rolling out the feature flag or do you think we should also handle the gradle wrapper update failures and after that we can roll out the feature flag?

[yeikel]

@gmazzo , @yeikel since currently gradle wrapper update works, what do you think about rolling out the feature flag or do you think we should also handle the gradle wrapper update failures and after that we can roll out the feature flag?

Currently, only the property files are being updated. Are you OK rolling that initially?

The following items are open:

• The gradle wrapper should be called instead of the globally installed gradle instance : Not a blocker, but it should be a follow up change
• The gradle wrapper should be executed again to update the wrapper-related files. This will fail for some people until we decide what we should do with the failures

[kbukum1]

@gmazzo , @yeikel since currently gradle wrapper update works, what do you think about rolling out the feature flag or do you think we should also handle the gradle wrapper update failures and after that we can roll out the feature flag?

Currently, only the property files are being updated. Are you OK rolling that initially?

The following items are open:

• The gradle wrapper should be called instead of the globally installed gradle instance : Not a blocker, but it should be a follow up change
• The gradle wrapper should be executed again to update the wrapper-related files. This will fail for some people until we decide what we should do with the failures

Thanks @yeikel for outlining the outstanding items. I agree that it’s best to hold off for now, since rolling out the feature flag as-is could impact existing Gradle users, especially those relying on dependency updates. Once we make the Gradle wrapper update optional, users can opt in when they’re ready.

Additionally, rather than adding another choice, have we considered treating gradle-wrapper as a separate ecosystem, rather than mixing it with gradle? This way, users who specifically want to update their Gradle wrapper could simply include an ecosystem update for gradle-wrapper, keeping the processes distinct.

Would love to hear thoughts from @yeikel, @gmazzo, @ryanbrandenburg, and @honeyankit.

[yeikel]

Additionally, rather than adding another choice, have we considered treating gradle-wrapper as a separate ecosystem,

I previously suggested this approach in my original review to help with isolating the components. @gmazzo and I had a valuable discussion in that PR, which is worth revisiting, as each method has its advantages and drawbacks.

The decision we make will also impact the Maven wrapper, since I plan to propose a similar feature once we finalize the behavior for the Gradle wrapper.

[gmazzo]

gradle wrapper update works, what do you think about rolling out the feature flag

Can we wait a bit? I 'd like to work on @yeikel 's outstanding items first

Once we make the Gradle wrapper update optional,
have we considered treating gradle-wrapper as a separate ecosystem

Actually this was proposed by @yeikel in the first PR. I was advocating for the opposite, and at the end, we were waiting feedback from you on that.

I'd like to understand the rationale of this. Why would it be treated differently? The way I see it's just another piece of the same system. The only reason why it was but there before was because it's implementation was different than Maven/Gradle regular dependencies right?

By the way, if some wants to opt-out, they can always disable the gradle-wrapper dependency in Dependabot standard config.

But if we want an opt-in behavior otherwise, we should move it to a dedicated manager, or, if possible, set the feature flag in the configs itself. That's is going to be a bigger effort. Are you accepting new managers right now? I remember someone tagging the original PR because another blocked PR.

[yeikel]

Actually this was proposed by @yeikel in the first PR. I was advocating for the opposite, and at the end, we were waiting feedback from you on that.
I'd like to understand the rationale of this. Why would it be treated differently? The way I see it's just another piece of the same system. The only reason why it was but there before was because it's implementation was different than Maven/Gradle regular dependencies right?

I think that my last two paragraphs here summarize the reason to separate them.

It is a subjective opinion. And there is no right answer.

What separating would allow is to collect feedback without special feature flags

By the way, if some wants to opt-out, they can always disable the gradle-wrapper dependency in Dependabot standard config

In most beta releases, the team tries to ask users to opt-in, and as far as I know, it is not possible to opt-in for feature flags

A different ecosystem would allow us to create a "beta ecosystem" and collect feedback separately

Are you accepting new managers right now? I remember someone tagging the original PR because another blocked PR.

Yes, the team is accepting new ecosystems now. For example #13091

Before we take a stance on that, let's please wait for @ryanbrandenburg, and @honeyankit to comment as it is a large change as you mentioned

[gmazzo]

By the way, regarding this, I think both are the same and it's just a defect. I managed to reproduce it locally just now:

The following items are open:

• The gradle wrapper should be called instead of the globally installed gradle instance : Not a blocker, but it should be a follow up change
• The gradle wrapper should be executed again to update the wrapper-related files. This will fail for some people until we decide what we should do with the failures

So the thing is, if you run gradle wrapper --gradle-version=9.2.0 --no-daemon, with a installed older Gradle version, like 8.14.3, then the wrapper binaries are never updated (assuming the project is already at 8.14.3). No matter how many times you run it. I think it's picking the binaries from "command" itself (either system's gradle or adhoc ./gradlew). Probably on Dependabot's we dont' have Gradle 9 yet. That will explain why it did work on my local tests, and the smoke tests (since we were bumping from 7 to 8) but not on real updated projects.

I'm going to work on addressing the pending stuff assuming that's the issue, it would be nice if someone else can confirm it.

Also, in the logic, we are first updating the requirements, and later running the native commands. So at the time we run it, the gradle-wrapper.properties file is updated to the latest version already.

[marcindabrowski]

Additionally, rather than adding another choice, have we considered treating gradle-wrapper as a separate ecosystem, rather than mixing it with gradle? This way, users who specifically want to update their Gradle wrapper could simply include an ecosystem update for gradle-wrapper, keeping the processes distinct.

I'd like to understand the rationale of this. Why would it be treated differently? The way I see it's just another piece of the same system.

At first I tought that it should be another ecosystem, because gradle wrapper is not distributed via Maven Central. But on the other hand why I should put something more, when in my config i enable gradle ecosystem? Gradle wrapper is part of Gradle anyway, the only difference is the distribution channel, so why should I declare new ecosystem?

Similar solution should be implemented for Maven.

And again I would like to vote to have possibliby for creating PRs with Gradle bump even if they are failing - this will give me an information that new Gradle version is out and I have to do something to bump it.
Sometimes it will be bumping some plugins that are not compatible with new version of Gradle, and somethimes it will require some changes in build scripts.

[marcindabrowski]

So the thing is, if you run gradle wrapper --gradle-version=9.2.0 --no-daemon, with a installed older Gradle version, like 8.14.3, then the wrapper binaries are never updated (assuming the project is already at 8.14.3). No matter how many times you run it. I think it's picking the binaries from "command" itself (either system's gradle or adhoc ./gradlew). Probably on Dependabot's we dont' have Gradle 9 yet. That will explain why it did work on my local tests, and the smoke tests (since we were bumping from 7 to 8) but not on real updated projects.

That's true. And this is why Gradle in upgrade instructions is putting these two commands:

./gradlew wrapper --gradle-version=9.2.1 && ./gradlew wrapper

[kbukum1]

@yeikel , @gmazzo

I just used copilot to fix some issues. Can you check the following Draft PR, if that is going to fix some of issues we have regarding updating wrapper?

• gradle: Fix wrapper updater to update all 4 wrapper files #13578

[gmazzo]

@yeikel , @gmazzo

I just used copilot to fix some issues. Can you check the following Draft PR, if that is going to fix some of issues we have regarding updating wrapper?

• gradle: Fix wrapper updater to update all 4 wrapper files #13578

I think #13578 has some flaws. I did a quick review, and for instance, is picking ./gradlew or gradle.bat based on existence rather than host OS.

Actually, just opened #13579 "fixing" the issues. I'll probably need to iterate it a bit more, but it seems it's working now. I plan to test it against a real repos too.

[yeikel]

@kbukum1 @gmazzo Thank you for putting the effort to move this forward

Unfortunately, I am not sure where to send feedback now because we have two "competing changes" and it may be better if we can consolidate. Can we merge both into a single pull request?

@kbukum1 Are we proceeding with an initial release where dependabot will fail if the upgrade is incomplete or should we wait for the gradle team first?

I think #13578 has some flaws. I did a quick review, and for instance, is picking ./gradlew or gradle.bat based on existence rather than host OS.

This should not be needed. See my comment

[kbukum1]

@yeikel , @gmazzo
I just used copilot to fix some issues. Can you check the following Draft PR, if that is going to fix some of issues we have regarding updating wrapper?

• gradle: Fix wrapper updater to update all 4 wrapper files #13578

I think #13578 has some flaws. I did a quick review, and for instance, is picking ./gradlew or gradle.bat based on existence rather than host OS.

Actually, just opened #13579 "fixing" the issues. I'll probably need to iterate it a bit more, but it seems it's working now. I plan to test it against a real repos too.

@kbukum1 @gmazzo Thank you for putting the effort to move this forward

Unfortunately, I am not sure where to send feedback now because we have two "competing changes" and it may be better if we can consolidate. Can we merge both into a single pull request?

@kbukum1 Are we proceeding with an initial release where dependabot will fail if the upgrade is incomplete or should we wait for the gradle team first?

I think #13578 has some flaws. I did a quick review, and for instance, is picking ./gradlew or gradle.bat based on existence rather than host OS.

This should not be needed. See my comment

@gmazzo, @yeikel – I'm good with proceeding using @gmazzo's PR. My draft was mainly to surface and explore some of the issues. For the OS selection, I agree—it's not quite handled properly, just a quick approach for demonstration.

A couple things to consider:

• @gmazzo, do you know if Gradle caches the wrapper installation automatically, or do we need to handle caching ourselves to avoid repeated network calls during updates?

Open to merging ideas if needed, but happy to consolidate on your PR if it looks solid!

[yeikel]

A couple things to consider:

* @gmazzo, do you know if Gradle caches the wrapper installation automatically, or do we need to handle caching ourselves to avoid repeated network calls during updates?

From what I tested, it seems to cache in .gradle/caches/ so multiple calls to result in a single download

[yeikel]

For what it’s worth, I tested the a few of the main open-source tools used to keep the Gradle wrapper up to date.

• The update-gradle-wrapper-action fails if the wrapper files cannot be updated: https://github.com/yeikel/grails-core/actions/runs/19454659242/job/55666186019
• Renovate, on the other hand, creates a partial pull request but no warning: https://github.com/yeikel/grails-core/actions/runs/19454954269/job/55667031192 , pull request: https://github.com/yeikel/grails-core/pull/4/files

For what is worth, in Renovate, it is a separate ecosystem

This isn’t necessarily a reason for Dependabot to behave in any specific way, but it’s something worth keeping in mind.

Personally, I prefer an approach like Renovate, where a pull request is created even if the generation fails, but only if a clear warning is included for the user within the pull request. I do not believe we should implement a solution that does not inform the user that Dependabot tried(and failed) to update the wrapper files as that will cause confusion and invalid defects

Something like

⚠️ Note: Dependabot tried to update the wrapper files but the build failed. See the logs for more details

[gmazzo]

do you know if Gradle caches the wrapper installation automatically, or do we need to handle caching ourselves to avoid repeated network calls during updates?

Yes, it's cached at user's home. As @yeikel pointed out

but only if a clear warning is included for the user within the pull request

It would be nice if someone can point me out if there is an API already to collaborate from a dependency update into the final PR body that I can use for this.

Are we proceeding with an initial release where dependabot will fail if the upgrade is incomplete or should we wait for the gradle team first?

I'd wait for this PR first, to have a fully "working" approach

Dependabot only supports Linux runners.

Great, less complexity then 💪

[yeikel]

but only if a clear warning is included for the user within the pull request

It would be nice if someone can point me out if there is an API already to collaborate from a dependency update into the final PR body that I can use for this.

@gmazzo To clarify, this is my opinion and not a final design alignment. Let's wait for confirmation from the Dependabot team before discussing design or how to tackle this.

@kbukum1 The sooner we can reach an agreement on the desired behavior, the better, so we can begin rolling this out. Any chance you can connect with @honeyankit /team this week?

[kbukum1]

For what it’s worth, I tested the a few of the main open-source tools used to keep the Gradle wrapper up to date.

• The update-gradle-wrapper-action fails if the wrapper files cannot be updated: https://github.com/yeikel/grails-core/actions/runs/19454659242/job/55666186019
• Renovate, on the other hand, creates a partial pull request but no warning: https://github.com/yeikel/grails-core/actions/runs/19454954269/job/55667031192 , pull request: https://github.com/yeikel/grails-core/pull/4/files

For what is worth, in Renovate, it is a separate ecosystem

This isn’t necessarily a reason for Dependabot to behave in any specific way, but it’s something worth keeping in mind.

Personally, I prefer an approach like Renovate, where a pull request is created even if the generation fails, but only if a clear warning is included for the user within the pull request. I do not believe we should implement a solution that does not inform the user that Dependabot tried(and failed) to update the wrapper files as that will cause confusion and invalid defects

Something like

⚠️ Note: Dependabot tried to update the wrapper files but the build failed. See the logs for more details

I think we can discuss & (hopefully implement that seperatelly). We may need to use our existing common notices to be able to add warning. I am saying that because PR creation is a common approach and we normally do not customize things directly from ecosystem to PR creation. However, I remember we did create notice approach so that any ecosystem can pass warnings into PR descriptions.

Here is a PR that may help for that

• Sending Bundler v1 Deprecation Warning Alert #10485

[yeikel]

I think we can discuss & (hopefully implement that seperatelly)

Thank you for the reference. Should we implement an initial version where it just fails if the wrapper update fails?

We can create a follow up feature to allow partial updates + a warning

[marcindabrowski]

I think that one more think is not implemented.
In Gradle you can have two distribution types used for the Wrapper - all and bin. The bin is the default, but if in gradle-wrapper.properties you have all you should add --distribution-type=all switch. Otherwise it will change type of distribution from all to bin in updated gradle-wrapper.properties file.

https://docs.gradle.org/current/userguide/gradle_wrapper.html

[gmazzo]

In Gradle you can have two distribution types used for the Wrapper - all and bin. The bin is the default, but if in gradle-wrapper.properties you have all you should add --distribution-type=all switch.

This is implemented already in this PR https://github.com/dependabot/dependabot-core/pull/13579/files#diff-25c6c1fa1ac7e0ccd7742c8143ec3bfead5f231bc84581ba1b01921c7ed212aaR106

[yeikel]

For what it’s worth, I tested the a few of the main open-source tools used to keep the Gradle wrapper up to date.

• The update-gradle-wrapper-action fails if the wrapper files cannot be updated: https://github.com/yeikel/grails-core/actions/runs/19454659242/job/55666186019
• Renovate, on the other hand, creates a partial pull request but no warning: https://github.com/yeikel/grails-core/actions/runs/19454954269/job/55667031192 , pull request: https://github.com/yeikel/grails-core/pull/4/files

For what is worth, in Renovate, it is a separate ecosystem
This isn’t necessarily a reason for Dependabot to behave in any specific way, but it’s something worth keeping in mind.
Personally, I prefer an approach like Renovate, where a pull request is created even if the generation fails, but only if a clear warning is included for the user within the pull request. I do not believe we should implement a solution that does not inform the user that Dependabot tried(and failed) to update the wrapper files as that will cause confusion and invalid defects
Something like

⚠️ Note: Dependabot tried to update the wrapper files but the build failed. See the logs for more details

I think we can discuss & (hopefully implement that seperatelly). We may need to use our existing common notices to be able to add warning. I am saying that because PR creation is a common approach and we normally do not customize things directly from ecosystem to PR creation. However, I remember we did create notice approach so that any ecosystem can pass warnings into PR descriptions.

Here is a PR that may help for that

• Sending Bundler v1 Deprecation Warning Alert #10485

I logged #13597 as a summary of the design decisions and next steps we can consider

[kbukum1]

I think we can discuss & (hopefully implement that seperatelly)

Thank you for the reference. Should we implement an initial version where it just fails if the wrapper update fails?

We can create a follow up feature to allow partial updates + a warning

That's sounds better approach