# Gradle's CI bot summarizes Develocity test failures on pull requests

DevFeed: [Gradle's CI bot summarizes Develocity test failures on pull requests](<https://devfeed.tech/articles/the-red-x-that-says-what-it-saw-24615.md>)

Original publisher: [Read original article](<https://blog.gradle.org/dogfooding-failure-summaries>)

Author: Laura Kassovic

Published: 2026-08-11T04:00:00Z

Content type: opinion

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [ci](<https://devfeed.tech/topics/ci.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [ci](<https://devfeed.tech/tags/ci.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>)

## AI overview

The article describes a Gradle CI bot that reads failures from Develocity, groups related failures, and posts concise summaries on pull requests. A documented example shows the summary identifying a test that unexpectedly passed despite being marked as expected to fail under Configuration Cache.

## Source excerpt

A failing CI check knows exactly what went wrong. It was there. It watched the exception get thrown, caught the stack trace, wrote the whole thing down. And then, by long tradition, it tells you almost none of it: a red X, a job name, and an invitation to go read the logs yourself. Our CI bot has commented on pull requests in gradle/gradle for years: triggering builds on request, shepherding the merge queue, answering commands. In mid-July we gave it one more job. When a check goes red, it reads the failures out of Develocity, groups them, and posts a short summary on the pull request, so the red X finally has to say what it saw. A real failure Take pull request #38047, a change that gives the Copy and Sync tasks a lazy destinationDirectory property. Additive, non-breaking, the kind of change you expect to sail through. Most of its checks came back green. One did not. Here is what the bot left on the pull request: You can read the entire shape of the failure without opening anything. It is a single test, named in full: CachedTaskActionIntegrationTest, the case "ad hoc tasks with the same action share results," in :core:configCacheIntegTest. And it is the good kind of surprising. The test was marked to be fixed: a known limitation, annotated as expected to fail under the Configuration Cache. Except it did not fail. It passed. Expected the test to fail in 'Configuration Cache' mode, but it succeeded! The change had quietly fixed something a stale annotation still insisted was broken, and the build stopped to point it out. The comment links straight into the Build Scan. Open it, and the failure is waiting on the summary: That is the Build Scan for the failing build, and the failure is sitting right in the summary: the same test named again, the ToBeFixedUnexpectedSuccessException spelled out, and, because this is Develocity, the test's own history next to it: 713 runs in the last seven days, 536 passed, 7 failed. The comment is the headline. The Build Scan is the story