New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate the arguments
parameter
#996
Comments
@bigdaz Do you have plans to actually rename it to |
@TWiStErRob Yes, something like that is the plan. The action repo was earlier renamed from I'm not sure if the final name will be
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). |
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. |
Running gradle via gradle-build-action is no longer supported, instead it is recommended to use a run step - see: gradle/gradle-build-action#996
Running gradle via gradle-build-action is no longer supported, instead it is recommended to use a run step - see: gradle/gradle-build-action#996
Upgrade to gradle/actions/setup-gradle@v3, which claims to be backward-compatible with v2 (with the exception of requiring node 20) The `arguments` parameter is now deprecated (it is recommended to "setup" in one step and to use the standard "run" action in a separate step), see: See: gradle/gradle-build-action#996 However, for this PR we'll just upgrade to the latest version. We'll deal with the deprecation in a separate PR.
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 subsequentrun
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.The text was updated successfully, but these errors were encountered: