As these actions evolve, certain inputs, behaviour and usages are deprecated for removal. Deprecated functionality will be fully supported during the current major release, and will be removed in the next major release. Users will receive a deprecation warning when they rely on deprecated functionality, prompting them to update their workflows.
The gradle-build-action action has evolved, so that the core functionality is now to configure the
Gradle environment for GitHub Actions. For clarity and consistency with other action (eg setup-java, setup-node), the gradle-build-action has been replaced by the setup-gradle action.
As of v3.x, the setup-gradle and gradle-build-action actions are functionally identical,
and are released with the same versions.
To convert your workflows, simply replace:
uses: gradle/gradle-build-action@v3
with
uses: gradle/actions/setup-gradle@v4
To facilitate ongoing development, the wrapper-validation-action action implementation has been merged into
the https://github.com/gradle/actions repository, and the gradle/wrapper-validation-action has been replaced by the gradle/actions/wrapper-validation action.
As of v3.x, the gradle/wrapper-validation-action and gradle/actions/wrappper-validation actions are
functionally identical, and are released with the same versions.
In a future major version (likely v4.x) we will stop releasing new versions of gradle/wrapper-validation-action:
development and releases will continue in the gradle/actions/wrapper-validation action.
To convert your workflows, simply replace:
uses: gradle/wrapper-validation-action@v3
with
uses: gradle/actions/wrapper-validation@v4
The core functionality of the setup-gradle (and gradle-build-action) actions is to configure your
Gradle environment for GitHub Actions. Once the action has run, any subsequent Gradle executions will
benefit from caching, reporting and other features of the action.
Using the arguments parameter to execute Gradle directly is not necessary to benefit from this action.
This input is deprecated, and will be removed in the v4 major release of the action.
To convert your workflows, replace any steps using the arguments parameter with 2 steps: one to setup-gradle and another that runs your Gradle build.
For example, given a workflow like this:
steps:
- name: Assemble the project
uses: gradle/actions/setup-gradle@v3
with:
arguments: 'assemble'
- name: Run the tests
uses: gradle/actions/setup-gradle@v3
with:
arguments: 'test'
- name: Run build in a subdirectory
uses: gradle/actions/setup-gradle@v3
with:
build-root-directory: another-build
arguments: 'build'
Then replace this with a single call to setup-gradle together with separate run steps to execute your build.
The exact syntax depends on whether or not your project is configured with the Gradle wrapper.
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v4
- name: Assemble the project
run: ./gradlew assemble
- name: Run the tests
run: ./gradlew test
- name: Run build in a subdirectory
working-directory: another-build
run: ./gradlew build
- name: Setup Gradle for a non-wrapper project
uses: gradle/actions/setup-gradle@v4
with:
gradle-version: "8.10"
- name: Assemble the project
run: gradle assemble
- name: Run the tests
run: gradle test
- name: Run build in a subdirectory
working-directory: another-build
run: gradle build
Using the action in this way gives you more control over how Gradle is executed, while still giving you
all of the benefits of the setup-gradle action.
The arguments parameter is scheduled to be removed in setup-gradle@v4.
Note: if you are using the gradle-build-action, see here for more details on how to migrate.
With recent releases of the com.gradle.develocity plugin, key input parameters have been renamed.
build-scan-terms-of-service-urlis nowbuild-scan-terms-of-use-urlbuild-scan-terms-of-service-agreeis nowbuild-scan-terms-of-use-agree
The standard URL for the terms of use has also changed to https://gradle.com/help/legal-terms-of-use
To convert your workflows, change:
build-scan-publish: true
build-scan-terms-of-service-url: "https://gradle.com/terms-of-service"
build-scan-terms-of-service-agree: "yes"
to this:
build-scan-publish: true
build-scan-terms-of-use-url: "https://gradle.com/help/legal-terms-of-use"
build-scan-terms-of-use-agree: "yes"
These deprecated build-scan parameters are scheduled to be removed in setup-gradle@v4 and dependency-submission@v4.
Gradle Enterprise has been renamed to Develocity starting from Gradle plugin 3.17 and Develocity server 2024.1.
In v4 release of the action, it will require setting the access key with the develocity-access-key input and Develocity 2024.1 at least to generate short-lived tokens.
If those requirements are not met, the GRADLE_ENTERPRISE_ACCESS_KEY env var will be cleared out and build scan publication or other authenticated Develocity operations won't be possible.
In versions of the action prior to v4, the boolean gradle-home-cache-cleanup parameter allows users to opt-in
to cache cleanup, removing unused files in Gradle User Home prior to saving to the cache.
With v4, cache-cleanup is enabled by default, and controlled by the cache-cleanup input parameter.
To remove this deprecation:
- If you are using
gradle-home-cache-cleanup: truein your workflow, you can remove this option as this is now enabled by default. - If you want cache-cleanup to run even when a Gradle build fails, then add the
cache-cleanup: alwaysinput. - If cache-cleanup is causing problems with your workflow, you can disable it with
cache-cleanup: never.