GitHub Actions for Gradle v6: What's Changing and Why
Table of Contents
Introduction
Today, we’re releasing v6 of GitHub Actions for Gradle builds, with an important change to how the caching component is licensed. In this blog post, we explain what’s changing, what it means for you, and where we’re headed.
GitHub Actions for Gradle builds is a collection of GitHub Actions that makes it easy to configure and run Gradle builds on GitHub Actions CI. The centerpiece is setup-gradle, which provides a convenient way to invoke Gradle in GitHub Actions workflows with sophisticated, efficient caching across invocations, GitHub Dependency Graph support, automatic capture of Build Scan® links, and more. It’s used by over 45,000 open source repositories and is featured in GitHub’s official starter workflows.
Since its introduction, GitHub Actions for Gradle builds, including the caching implementation in setup-gradle, have been fully open source under the MIT license. That changes with v6.
What’s changing #
Starting with v6, the functionality of setup-gradle that saves and restores Gradle User Home state has been extracted to gradle-actions-caching, a closed-source library distributed under our Terms of Use. The rest of the action remains open source.
While the caching functionality of setup-gradle is now under a proprietary license, we are not introducing any functional restrictions in this release. Your workflows will continue to function as before.
The only functional change in v6 is the removal of the experimental Configuration Cache support. It was not production-ready and worked only for a limited set of projects. We’re reworking this feature so that it works for most projects and more users can benefit (more on this below).
To upgrade, simply update your workflow files to reference v6:
- uses: gradle/actions/setup-gradle@v6
By upgrading to v6, you accept the Terms of Use for the gradle-actions-caching component.
Why we’re making this change #
Supporting the caching infrastructure in setup-gradle requires a substantial engineering investment, which we can sustain thanks to Develocity, our commercial offering.
Build acceleration at scale, especially as AI-driven development increases the volume of CI builds, is a core part of our commercial offering at Gradle Technologies. The caching in setup-gradle fits squarely in that space.
This licensing change lets us 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.
Our commitment to open source #
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 with free Develocity licenses. Public repositories are primarily used by open source projects, and we remain committed to supporting them.
For teams that need more #
If you’re running Gradle builds at scale, especially on self-hosted runners, consider Develocity Universal Cache. It provides a unified, globally distributed caching layer with Develocity Edge nodes deployed close to your runners to reduce latency and enable more comprehensive caching across the entire build process. Together with Develocity 360, you get full observability into all your builds, their caching behavior, and where build time is spent. In addition to Gradle, Develocity also supports Maven, sbt, pip, and npm.