

About the Gradle Security Subscription
Today, we launched our new Gradle Security Subscription offering. And I made an infographic about it. But, because I am me, I also made a blog post about it. Choose wisely (or read both 😉).
Building a set of Gradle Agent Skills
I work at Gradle, and we are building agent skills. We have five candidates:
- Run Gradle correctly (
gradle-cli) — right task, right flags, version-aware - Best-practices lint (
gradle-bestpractices) — flag legacy patterns, suggest the current one - New project bootstrap (
gradle-init) — KMP scaffold, version catalog, convention plugins - Upgrade + deprecations (
gradle-update) — bump the wrapper, rewrite what broke - Configuration cache migration (
gradle-cc) — find what breaks CC, refactor it
Which of these would you actually use? What's missing?
Which Gradle task would you hand off to an AI agent?
I work at Gradle, and we're building agent skills. We currently have five candidates:
- Run Gradle correctly (gradle-cli) — right task, right flags, version-aware
- Best-practices lint (gradle-bestpractices) — flag legacy patterns, suggest the current one
- New project bootstrap (gradle-init) — Android/KMP scaffold, version catalog
- Upgrade + deprecations (gradle-update) — bump the wrapper, rewrite what broke
- Configuration cache migration (gradle-cc) — find what breaks CC, refactor it
Which would you actually use? What do you want to see instead?
Gradle Agent Skills Vote
We're building a set of Gradle Agent Skills. There are five candidates below:
gradle-cli— Run Gradle the right way. Teaches the agent correct./gradlewinvocation: which task to run, which flags matter, what's version-specific, and how to read the output. No more--stacktraceon everything and hoping.gradle-bestpractices— Lint your build against current conventions. Scans your build logic and flags what's off: legacy APIs,subprojects {}sprawl, misused configurations, and missing version catalogs. Points to the current recommended pattern for each finding.gradle-init— Bootstrap a new Gradle project. Sets up a working project from scratch: sensible defaults, version catalog, and a starter layout for KMP, Android, or Spring. Skips the hour of copy-pasting from an old repo or adding random libraries.gradle-upgrade— Upgrade Gradle and clear deprecations. Version-aware upgrade path: bumps the wrapper, finds deprecated usages in your build logic, and rewrites them for the target version. Handles the multi-step hops so you're not stuck three majors behind.gradle-cc-migrate— Make your build Configuration Cache compatible. Reads your build logic, finds what breaks the configuration cache, and refactors it — script-level state,Projectaccess at execution time, non-serializable task inputs. The single biggest build-speed win, minus the archaeology.
Which would help you most? Which one would you actually use? Do you have a better idea?
Resilient Sync in Gradle 9.7 and IntelliJ 2026.2
Until now, a single broken build script would fail the entire sync. Every script turned red and no more autocomplete.
Resilient sync fixes this. Gradle builds tooling models for every project that configured successfully and reports only the failures, so one broken convention plugin no longer takes down the other projects. You keep code completion and highlighting in the build logic you're repairing.
Write-up here: https://blog.gradle.org/resilient-sync
IntelliJ now displays the Gradle version catalog data as hints
Small IntelliJ IDEA win for Gradle users: version catalog accessors now show their resolved coordinates inline.
We put Develocity failure grouping on every gradle/gradle PR
Our CI bot now reads failures out of Develocity, groups them, and posts a short summary on the PR. If you want to see it in action, here's my write-up with screenshots: https://blog.gradle.org/dogfooding-failure-summaries
Isolated Projects incubating in Gradle 9.7.0 (AndroidX sync 4m00s → 2m47s)
Isolated Projects moved from experimental to incubating in Gradle 9.7.0.
When it's on, each project is isolated from the others, which lets Gradle configure them in parallel instead of one at a time:
- AndroidX (1,000+ projects): Gradle's portion of Android Studio sync 4m00s → 2m47s
- An Android monorepo of 5,000+ projects: full Android Studio sync 5m09s → 2m44s
AGP and KGP are compatible, but other Gradle plugins may not be. "Now in Android" was made compatible if you want a reference build.
Blog Post: https://blog.gradle.org/introducing-isolated-projects
Gradle 9.7.0 Release Notes: https://docs.gradle.org/current/release-notes.html
Isolated Projects is now incubating in Gradle 9.7.0
Isolated Projects moved from experimental to incubating in 9.7.0. With it enabled, each project in a build is isolated from the others, which lets Gradle configure them in parallel.
Some numbers from the blog post:
- Gradle's own build (300 subprojects): median IDE sync 84s → 47s
- A 2,500-project Java monorepo: configuration with build-script recompilation 10m53s → 2m59s
- An Android monorepo of 5,000+ projects: Android Studio sync 5m09s → 2m44s
Configuration Cache is a prerequisite.
You can enable it with org.gradle.isolated-projects=true in gradle.properties.
Here's the full blog post: https://blog.gradle.org/introducing-isolated-projects.
Gradle 9.7.0 is out!
https://docs.gradle.org/9.7.0/release-notes.html
Bug fixes and…
- 🌱 Isolated Projects graduates to incubating
- ⚡ Broader Configuration Cache compatibility
- 🔍 More source locations in problem reports
Please report any 🐛 on GitHub!
Three Gradle Talks from KotlinConf 2026
Blog post with reviews: https://blog.gradle.org/gradle-at-kotlinconf-2026
YouTube links:
This is how the Gradle team adopted IP (Isolated Projects)
IP is the next step in Gradle's evolution, so we wrote about how we adopted it as a daily driver, what we learned, and its actual impact: https://blog.gradle.org/isolated-projects-in-gradle-team
A quick note on our company rebrand (and the Gradle Build Tool)
Our company renamed itself from Gradle Technologies to Develocity. The Gradle Build Tool is not renamed, not acquired, and not relicensed. You can learn a little more here if you are interested: https://blog.gradle.org/the-company-formerly-known-as-gradle
Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests
How the Gradle team triages ~110 GitHub issues a month: https://blog.gradle.org/triaging-gradle-github-issues
You are probably already running gradle/actions
blog.gradle.orgGradle is Javamaxxing
Why the Gradle Build Tool aggressively chases the newest JDK.