Add workflow for Update Gradle Wrapper Action.

[cristiangreco]

Hey there 👋, first of all thanks for your work on the TestContainers project!

I've got a suggested change: would you be willing to use this GitHub Action to automatically keep Gradle Wrapper updated to latest release?

What does "Update Gradle Wrapper Action" do? It can be configured to run at scheduled intervals (e.g. daily or weekly) and will check whether the Wrapper script in the repo is up-to-date to the latest Gradle release: in case a new Gradle version is available, it will create a PR to update the Wrapper. And that's it!

Why is that a good thing? Well, first of all it alleviates the chore of manually updating the Wrapper, as you got a task that keeps track of new Gradle releases for you! More importantly, it boosts security around the Wrapper update and usage processes: this actions verifies that the gradle-wrapper.jar file has not been tampered with (uses checksum comparison), and it sets the distributionSha256Sum property so that the new Gradle binary itself will be verified locally upon download.

Where can I find more about? The README contains quite detailed information!

In this PR I propose adding a new workflow which runs the action every day at midnight (but feel free to adjust the frequency as you prefer). I've verified it works correctly in my fork of the repo, and you can see here how a PR will look like.

The action is under active development, you can have a look at the list of inputs currently supported. There's new features coming up soon and if you'd like to request any particular change just let me know!

I'd love to see the action used by TestContainers and I genuinely hope you can find this useful. Would love your feedback! ❤️

[rnorth]

Hi @cristiangreco

I think as a general principle we'd want to use Dependabot for all version bumping - but it doesn't cover Gradle version upgrades, so there's definitely a gap that this action addresses!

I think I'd be happy with a couple of tweaks:

• For third party GitHub Actions we'd like to always use a SHA rather than an unpinned version or a tag reference. It's more of a chore for us to upgrade actions, but less risk if something in the chain gets compromised.
• Would it be possible to customise the labels that get applied to the PR? For our purposes we'd like to have the dependencies label applied. Could the action be updated to accept a list of labels that overrides the default?
• We'd like to use the Gradle-provided wrapper validation action as well, even though there's some crossover in functionality with your library. Having validation being done by Gradle's own code would help satisfy our paranoia :)

Thanks
Richard

[cristiangreco]

@rnorth thanks for your reply!

For third party GitHub Actions we'd like to always use a SHA rather than an unpinned version or a tag reference. It's more of a chore for us to upgrade actions, but less risk if something in the chain gets compromised.

It makes sense to me if you want to stay on the safe side. You might not automatically benefit from new functionalities or fixes as v1 continues to get updated, but I totally understand that you want to have more control over a 3rd party repo that is not part of the Gradle org.

Would it be possible to customise the labels that get applied to the PR? For our purposes we'd like to have the dependencies label applied. Could the action be updated to accept a list of labels that overrides the default?

Sure thing, will work on it! Would it be ok for your use case if the labels you specify are added to the one already set by the action?

We'd like to use the Gradle-provided wrapper validation action as well, even though there's some crossover in functionality with your library. Having validation being done by Gradle's own code would help satisfy our paranoia :)

This is totally doable, you can add another step in the workflow that runs the WVA just after UGW.

Will update the PR with all the changes mentioned above 🙂

[rnorth]

Thanks!

but I totally understand that you want to have more control over a 3rd party repo that is not part of the Gradle org.

It's not just not being part of the gradle org - actually we should use SHA pinning for the Gradle-provided action as well, because the same risk exists with that. We're just keen to make sure any action that isn't provided by GitHub themselves is pinned.

Sure thing, will work on it! Would it be ok for your use case if the labels you specify are added to the one already set by the action?

Yep, absolutely fine! As long as we can add a specific label, we don't mind which other labels are there.

Thanks again

[cristiangreco]

Hey @rnorth I've updated this PR with the requested changes:

• pinning to a sha (it's the one that corresponds to latest release, v1.0.9)
• setting an additional dependencies label
• additionally run the wrapper validation action at the end

Let me know if it looks ok to you 🙂

[bsideup]

👍

[rnorth]

Sorry, just spotted that the gradle action is not pinned!

[cristiangreco]

Sorry, just spotted that the gradle action is not pinned!

Sure, have committed your suggestion!

[rnorth]

Great, thanks!