Deprecate the `arguments` parameter

[bigdaz]

The gradle-build-action is designed to be used in a "setup Gradle" step, configuring the local Gradle installation and Gradle User Home so that all subsequent Gradle invocations will benefit.

With the arguments parameter, the action will perform exactly the same setup, but will then invoke Gradle with the specified arguments. This adds very little value (over a subsequent run step), and can lead to issues with correctly parsing input arguments or processing build output.

By deprecating the arguments parameter, we will push users toward the recommended "setup Gradle" approach for using this action.

[TWiStErRob]

@bigdaz Do you have plans to actually rename it to uses: gradle/setup-gradle@v3? to match all the other setup-ruby/setup-node/setup-java/setup-android/... actions and the intent of the action going forward? Note: the rename might be a non-breaking change because of GitHub's repository redirect feature (I haven't tested with actions yet, but 🤞).

[bigdaz]

@TWiStErRob Yes, something like that is the plan.

The action repo was earlier renamed from gradle/gradle-command-action to gradle/gradle-build-action and the repository redirect mostly worked, except I had some reports of issues from folks running GitHub Enterprise.

I'm not sure if the final name will be gradle/setup-gradle or if we want to consolidate a few different actions under a common repository, like:

• gradle/actions/setup-gradle
• gradle/actions/gradle-dependency-graph (pre-configured to generate-and-submit a dependency graph)
• gradle/actions/wrapper-validation
• etc.

If we do this, we have the benefit of a single repository for sharing code and development, but it will mean that all actions will be versioned together. I don't see this being much of an issue though. (The GitHub Actions release model is pretty brain-dead).

[TWiStErRob]

Nice, thanks for the detailed response. We decided for a mono-repo as well internally.

Note, there's an untested theory: we don't have to version everything together, we can create 3 tag prefixes, i.e. uses: gradle/actions/setup-gradle@setup-v4 or @v4.setup, whatever format makes Renovate/dependabot happy enough. This would mean one can use wrapper-validation@v4.setup, but hopefully people wouldn't, oh Murphy... :)