Wrapper upgrade plugin #61
Conversation
Signed-off-by: StefMa <[email protected]>
Signed-off-by: StefMa <[email protected]>
|
@ov7a wanna have a look at this? 😁 |
|
@StefMa sorry, I'm not confident enough to approve this. |
|
Sorry for coming so late back to you @ov7a 🙈 Yes, I agree that a plugin that checks for Gradle upgrades might be not the best decision to put into a project. Using the mentioned action could be an option, however, it seems it is a bit dated and seems not to be maintained anymore. (Not sure if required, but 🤷 ). On the other hand, other Gradle projects also using the gradle-wrapper-upgrade-plugin (examples PRs): Obviosuly I don't know how your organisation is structured and how far it make sense to streamline. Maybe this is a solution for you as well? 🤔 |
|
For this project it's not useful to automatically update the wrapper whenever there is a Gradle release. The plugin works with all kinds of Gradle versions, regardless which wrapper it's built with. So we have nothing to gain from automatic updates, but we can easily break the build of this project. So I guess we shouldn't do this. |
Thats the default for Gradle plugins, no? 😁
Wait... what?! As a Gradle employee you tell me that automated Gradle updates or using the latest (marked by Gradle as stable) Gradle (wrapper) version in projects "can easily break the build"? Isn't Gradle itself advocating that "each and every project" should use the "latest Gradle version when possible"? |
fixes #59
The GH aciton workflow was more or less copied from the gradle-wrapper-upgrade project itself.
👉 Link to their workflow file
Please notice that I removed the commit signing part here.
I'm not sure if this is/was a requirement for you. But to make this PR easy and straightforward I left them out.
Let me know if you want to include it.
If so, add the key and password to this repository (if not already added via the Gradle GitHub organisation) and I will add the respective code parts.
To note is also that the pull request create by this workflow does not run any tests❗
This is due to the fact that we are using the
secrets.GITHUB_TOKEN.Any PR that were created by an action can't trigger other actions by design.
So in case we want to run tests also on wrapper upgrade PRs (which make sense IMHO), you have to provide another secret and invite the respective user of this secret to this repo as collaborator with write access.
You might want to use your
bot-githubactionfor that 🙃 Seems this bot is designed for such tasks 😁Here is an example of how such an PR could look like.
Notice that it doesn't run any tests. Only the DCO check runs (because of I don't know the reason 🙈 )