The Red X that Says What it Saw
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Gradle's CI bot now posts failure summaries directly on gradle/gradle pull requests when a check goes red. Using Develocity's failure grouping, the bot reads grouped failures tied to a commit, drills into a representative build to recover human-readable test names, and posts a concise comment with a direct link to the relevant Build Scan. The feature was deployed without touching any workflow files in the main repository, runs in the existing bot service, and fails silently when data is unavailable. A real example shows how a single flaky test annotation was caught — a test marked 'to be fixed' unexpectedly passed, and the summary surfaced that immediately. Cross-build baseline comparison (detecting whether a failure is new vs. pre-existing on main) is not yet implemented but is described as the next planned feature.
Table of contents
Table of ContentsIntroductionA real failure #How it gets there #What we didn’t ship, yet #The parts worth stealing #DiscussQuestions this post answers
How does Gradle's CI bot post failure summaries on pull requests using Develocity?
The bot queries Develocity for failure groups tied to the commit, then drills one level deeper into a representative build's failures to recover the human-readable name of the failing test or task. It posts a short comment on the pull request with the grouped failure name and a direct deep link into the Build Scan, where the full assertion and stack trace are waiting. The feature runs in the existing bot service with no changes to workflow files in the main repository. Teams wiring up similar CI feedback loops track Develocity and Gradle build tooling developments on daily.dev.
What is Develocity failure grouping and how does it reduce noise in large Gradle builds?
Develocity failure grouping clusters failures that are, to a human, the same failure across all builds in a run rather than reporting them one at a time. A single gradle/gradle check fans out into dozens of builds across operating systems and test buckets; grouping collapses the same failure seen across many builds into one line. Without it, a single root-cause failure could appear as dozens of separate stack traces to scroll past. Developers managing large multi-build CI pipelines find coverage of Gradle and build tooling on daily.dev.