Files
actions/README.md
Daz DeBoer a0ee12f71e Extract caching logic into a separate gradle-actions-caching component (#885)
With this change, the caching functionality of `setup-gradle` and
`dependency-submission` is now provided by `gradle-actions-caching`, a
closed-source library distributed under our [Terms of
Use](https://gradle.com/legal/terms-of-use/). The rest of the action
implementation remains open source.

Using `setup-gradle` or `dependency-submission` with caching enabled
involves loading and using the `gradle-actions-caching` component,
requiring acceptance of the [Terms of
Use](https://gradle.com/legal/terms-of-use/). There are no functional
changes to caching provided by these actions: all workflows will
continue to function as before.

The non-caching aspects of action implementation remain open source. By
running these actions with caching disabled they can be used without
ever loading `gradle-actions-caching` or accepting the license terms.

Supporting the caching infrastructure in this project requires a
substantial engineering investment by Gradle Technologies, which we can
sustain thanks to Develocity, our commercial offering. Caching
technologies are a core part of the Develocity offering, and the caching
in `setup-gradle` fits squarely in that space.

This licensing change lets us continue to build advanced capabilities
that go beyond what we would offer as open source. Proper
production-ready Configuration Cache support will be the first
capability. Improving build performance for self-hosted runners will
follow.

We may introduce functionality restrictions in future updates. However,
caching functionality will remain free for public repositories.
We have a long-standing commitment to open source, as maintainers of
Gradle Build Tool, and by [sponsoring the open source
community](https://gradle.com/oss-sponsored-by-develocity/) with free
Develocity licenses. Public repositories are primarily used by open
source projects, and we remain committed to supporting them.

- Implementation of caching logic to save and restore Gradle User Home
content has been removed, replaced by the `gradle-actions-caching`
component.
- The `@actions/caching` library is still used to cache Gradle
distributions that are downloaded and provisioned by `setup-gradle`.
This PR updates to the latest version of `@actions/caching`, and removes
the patch that is no longer required.
- License notices are now displayed in documentation, logs and the
generated Job Summary.
2026-03-18 14:57:27 -06:00

117 lines
4.2 KiB
Markdown

# GitHub Actions for Gradle builds
This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.
> [!IMPORTANT]
> ## Licensing notice
>
> The software in this repository is licensed under the [MIT License](LICENSE).
>
> The caching functionality in this project has been extracted into `gradle-actions-caching`, a proprietary commercial component that is not covered by the MIT License for this repository.
> The bundled `gradle-actions-caching` component is licensed and governed by a separate license, available at https://gradle.com/legal/terms-of-use/.
>
> The `gradle-actions-caching` component is used only when caching is enabled and is not loaded or used when caching is disabled.
>
> Use of the `gradle-actions-caching` component is subject to a separate license, available at https://gradle.com/legal/terms-of-use/.
> If you do not agree to these license terms, do not use the `gradle-actions-caching` component.
## The `setup-gradle` action
The `setup-gradle` action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.
This replaces the previous `gradle/gradle-build-action`, which now delegates to this implementation.
The recommended way to execute any Gradle build is with the help of the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html), and the examples assume that the Gradle Wrapper has been configured for the project. See [this example](docs/setup-gradle.md#build-with-a-specific-gradle-version) if your project doesn't use the Gradle Wrapper.
### Example usage
```yaml
name: Build
on:
push:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout sources
uses: actions/checkout@v4
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: 17
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v5
- name: Build with Gradle
run: ./gradlew build
```
See the [full action documentation](docs/setup-gradle.md) for more advanced usage scenarios.
## The `dependency-submission` action
Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.
The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the
Dependency Submission API. For most projects, this default configuration should be all that you need.
Simply add this as a new workflow file to your repository (eg `.github/workflows/dependency-submission.yml`).
```yaml
name: Dependency Submission
on:
push:
branches: [ 'main' ]
permissions:
contents: write
jobs:
dependency-submission:
runs-on: ubuntu-latest
steps:
- name: Checkout sources
uses: actions/checkout@v4
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: 17
- name: Generate and submit dependency graph
uses: gradle/actions/dependency-submission@v5
```
See the [full action documentation](docs/dependency-submission.md) for more advanced usage scenarios.
## The `wrapper-validation` action
The `wrapper-validation` action validates the checksums of _all_ [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) JAR files present in the repository and fails if any unknown Gradle Wrapper JAR files are found.
The action should be run in the root of the repository, as it will recursively search for any files named `gradle-wrapper.jar`.
Starting with v4 the `setup-gradle` action will [perform wrapper validation](docs/setup-gradle.md#gradle-wrapper-validation) on each execution.
If you are using `setup-gradle` in your workflows, it is unlikely that you will need to use the `wrapper-validation` action.
### Example workflow
```yaml
name: "Validate Gradle Wrapper"
on:
push:
pull_request:
jobs:
validation:
name: "Validation"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: gradle/actions/wrapper-validation@v5
```
See the [full action documentation](docs/wrapper-validation.md) for more advanced usage scenarios.