Artifactory as the system of record, plus Develocity Artifact Cache serving builds locally, means faster builds without giving up provenance. Full write-up: https://develocity.ai/blog/artifact-cache-jfrog-artifactory-better-together/

Why Artifact Cache and JFrog Artifactory are better together in the GenAI era | Develocity

AI surged code volume and made the CI pipeline the new bottleneck. Keep JFrog Artifactory as your system of record and add Develocity Artifact Cache to serve artifacts locally -- faster builds, lower egress, provenance intact.

develocity.ai

Artifact Cache isn't a build-file setting — it's a CLI step on your CI agent, served from a nearby Edge: # CI step, before the build artifact-cache restore --dv-server=https://develocity.example.com Restore deps before the build, store after. Your repo manager stays the system of record

Real talk: flaky test detection tells you which tests are unreliable. It doesn't fix them for you. That part's still on your team — worth saying out loud.

Debugging a build failure and debugging a flaky test are different skills. One is deterministic. The other is basically epidemiology.

Quarantining a flaky test isn't giving up — it's triage: // build.gradle tasks.test { exclude '**/FlakyThing*' } Fix it properly later, off the critical path, without blocking everyone else's builds.

The 2026.2 release notes are out. Buried in there: an agent that diagnoses cache misses for you instead of you doing it at 11pm. https://develocity.ai/releases/2026.2

Develocity 2026.2

Release notes and updates for Develocity 2026.2

develocity.ai

Three Gradle talks from KotlinConf 2026, recapped so you can pick which ones deserve your 15 minutes. 1. Paul Merlin on the DSLs. 2. Stefan Wolf on 10 best practices. 3. Marcin Mycek on Declarative Gradle. https://blog.gradle.org/gradle-at-kotlinconf-2026

Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)

Recaps of the three Gradle talks from KotlinConf 2026, DSLs, best practices, and Declarative Gradle, with a few takeaways from each.

blog.gradle.org

The moment a team starts saying "it's probably just flaky" is the moment real regressions start hiding in plain sight. Flaky tests aren't harmless — they're a trust problem wearing a technical costume.

If your team's default response to a red build is "just rerun it," read this before it gets worse: https://develocity.ai/resources/ebooks-and-whitepapers/flaky-tests/

The Gradle team has been using Isolated Projects daily on our own build. Over six months: median IDE sync roughly halved (~1m24s → ~47s), and p95 dropped from ~7 min to just over 3. How we migrated and measured it: https://blog.gradle.org/isolated-projects-in-gradle-team

How the Gradle Team Adopted Isolated Projects

How the Gradle team adopted Isolated Projects as a daily driver, what we learned, and how we measured the impact.

blog.gradle.org

Our KotlinConf talk is up: A tale of the Gradle DSLs. Paul Merlin on how Gradle's build languages evolved -> Groovy, Kotlin DSL -> and where Declarative Gradle fits into what comes next. https://www.youtube.com/watch?v=k8T9IOnXPao

A tale of the Gradle DSLs | Paul Merlin

YouTube video by Kotlin by JetBrains

youtube.com

Marcin Mycek's KotlinConf talk is up on YouTube: A First Look at the Kotlin Ecosystem Plugin for Declarative Gradle. If you've been curious what Declarative Gradle means for Kotlin builds in practice, this is the place to start: https://youtu.be/25Ngfn9Bhqc

A First Look at the Kotlin Ecosystem Plugin for Declarative Gradle | Marcin Mycek

YouTube video by Kotlin by JetBrains

youtu.be

Here's a retry policy that actually works instead of infinite reruns: // settings.gradle develocity { testRetry { maxRetries = 1 maxFailures = 10 } } It caps the blast radius instead of hiding it forever.

Gradle Technologies is now Develocity. The Gradle Build Tool is not renamed, not acquired, and not relicensed. It remains free, open source, and Apache 2.0 at gradle.org. What changed, what didn't, and why: https://blog.gradle.org/the-company-formerly-known-as-gradle

The Company Formerly Known as Gradle

Our company renamed itself from Gradle Technologies to Develocity. The Gradle Build Tool is not renamed, not acquired, and not relicensed. Here's what changed, what didn't, and why.

blog.gradle.org

📣 Gradle 9.7.0 RC1 is out and ready for testing 🔬 https://docs.gradle.org/9.7.0-rc-1/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!

Gradle 9.7.0-rc-1 Release Notes

We are excited to announce Gradle 9.7.0-rc-1.

docs.gradle.org

Software shipped at human speed. AI just ended that. Gradle Technologies is now Develocity: same team and access, sharper focus on AI-driven delivery governance and efficiency. What changed and what stays the same: https://develocity.ai/blog/gradle-technologies-is-now-develocity/ #Develocity #AI

Every issue and PR on gradle/gradle now gets a human answer within a week. New on the blog: how we got there after retiring the stale bot, what our triage automation actually does, and how you can help us help you. https://blog.gradle.org/triaging-gradle-github-issues

No more stale bot. No more silence. Here's how the Gradle team now triages every issue and PR: https://blog.gradle.org/triaging-gradle-github-issues

Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests

Every issue and pull request on gradle/gradle now gets an answer within a week. Here is how we got there: retiring the stale bot, a response-time guarantee, triage automation, and what you can do to h...

blog.gradle.org

Ephemeral CI recomputes the same task outputs on every build. Gradle's Build Cache reuses them instead. Modest on our tiny sample (~11%), but on a real multi-module build it's the biggest lever you've got. Part 3, and the finale of the series: https://blog.gradle.org/gradle-on-ephemeral-ci-3

Essential Tips for Gradle on Ephemeral CI Environments - Part 3

Learn how the Gradle Build Cache helps ephemeral CI avoid repeated task execution, and how local, remote, and managed caches fit into the full optimization story.

blog.gradle.org

Ephemeral CI re-downloads the same dependencies every single build. Cache them and Gradle's configuration phase drops ~28%. We also tested caching processed JARs (~0%, don't bother). Part 2, with the numbers: https://blog.gradle.org/gradle-on-ephemeral-ci-2

Essential Tips for Gradle on Ephemeral CI Environments - Part 2

Learn practical strategies to optimize Gradle builds in ephemeral CI environments and keep your pipelines fast without relying on persistent state.

blog.gradle.org

Is Gradle slow on your ephemeral CI? It's mostly the startup phase, and every disposable runner starts cold. We benchmarked the fixes (Gradle 9.5.1, Docker, averaged runs). Part 1: https://blog.gradle.org/gradle-on-ephemeral-ci-1

Running your full test suite on every PR is a choice, not a requirement. Predictive Test Selection runs only the tests a change could affect. Same coverage on full CI runs. Faster feedback on PRs. Trained on your actual build history. https://develocity.ai/product/predictive-test-selection/

"Artifactory or Develocity Artifact Cache?" is the wrong question. They do different things. Artifactory is your system of record — governance, compliance, long-term storage. Artifact Cache is your local serving layer — fast, low-latency, low-egress. You want both.

Every public repo's CI config is world-readable. So I read how Spring Boot, OkHttp, Mockito, JUnit 5 & detekt actually run their builds. They disagree about almost everything, but quietly converged on the same GitHub Action. blog.gradle.org/running-gradle-github-actions

The three-layer cache stack: 1. Artifact Cache — deps before the build 2. Setup Cache — environment setup before the build 3. Build Cache — task outputs across builds Each layer covers a different class of repeated work. Most teams only have layer 3. gradle.com/develocity/product/universal-cache/

Develocity Universal Cache | One scalable, observable, secure caching platform for the entire SDLC

Universal Cache stores and reuses build input, setup, and output data to accelerate builds and tests and achieve a more stable delivery pipeline in today's AI software development landscape.

gradle.com

Ephemeral CI runners re-download hundreds of megabytes of dependencies on every cold start. At AI-generated commit volume, you're paying for that bandwidth and latency hundreds of times a day. Artifact Cache sits between your runners and the remote repo and eliminates most of it.

Artifact Cache and JFrog Artifactory are better together in the GenAI era. Artifactory stays your system of record. Develocity Artifact Cache serves deps locally to CI runners. Faster cold starts, lower egress, provenance intact. gradle.com/blog/artifact-cache-jfrog-artifactory-better-together/

Why Artifact Cache and JFrog Artifactory are better together in the GenAI era | Gradle Technologies

AI surged code volume and made the CI pipeline the new bottleneck. Keep JFrog Artifactory as your system of record and add Develocity Artifact Cache to serve artifacts locally -- faster builds, lower egress, provenance intact.

gradle.com

AI-assisted development stack that actually works: - AI generates code - Develocity PTS runs only affected tests - Build Cache skips unchanged outputs - Failure Analytics surfaces the root cause if it breaks Feedback in minutes, not hours.

📣 Gradle 9.6.0 is out! https://docs.gradle.org/9.6.0/release-notes.html Bug fixes and… 🎯 Improved Configuration Cache hit rates 💻 Additional CLI rendering options ⚠️ Important project hierarchy lookup deprecations Please report any 🐛 on GitHub!

Gradle 9.6.0 Release Notes

We are excited to announce Gradle 9.6.0.

docs.gradle.org

The feedback loop is the bottleneck. AI generates a PR in seconds. If CI takes 45 minutes, you've erased the advantage. Fast builds aren't a nice-to-have when AI is writing the code. They're the whole product.