Gradle Enterprise 2019.3 introduced a failures dashboard that partitions verification failures (compiling, linking, testing, linting, and so on) from non-verification failures.
The purpose of this feature is to highlight unexpected and disruptive failures, such as build configuration or infrastructure failures, from failures that are considered "a normal and acceptable part of the development process".
Build failures are classified based on information about the failure such as the exception message, stack trace, and identifying build information. This information is run through a classifier model to predict the best classification. Although this model was trained using thousands of different build failures, it may make classifications that don’t serve your needs perfectly.
Gradle Enterprise 2019.4 improved the classification model to support definitive error message prefix phrases for failure classification, as listed below. The presence of a prefix overrides all other heuristics and forces the failure to be classified accordingly. Failure exceptions are mined for the definitive prefixes from the inner most exception and then up chain of causes.
For your custom build logic, where you are in control of the failure exceptions thrown when something goes wrong, you can use one of the prefixes to force classification.
|The prefixes are not guaranteed to definitively classify when using Gradle Enterprise 2019.3 and earlier.|
This classification is meant for failures that are expected within a standard application development lifecycle. They typically represent a problem with the developer’s inputs to the build such as the source code.
To force classification of a build failure as a verification failure, prefix any exception message with any of the following phrases (case-insensitive) for verification failures.
Code generation failed
Using any of these will guarantee that Gradle Enterprise will classify your failure as verification.
This classification is mean for failures that are typically not expected during standard application development, such as build configuration failures, dependency resolution failures, infrastructure failures, and so on.
Prefix any exception message with "unexpected error" or "unexpected failure" (case-insensitive) to guarantee that Gradle Enterprise will classify this failure as a non-verification.
Currently, there is no way to customize failure classification in Gradle Enterprise. If you are unable to change the failure messages emitted by your build logic, you are reliant on the built-in classification model in Gradle Enterprise. If you believe the failure classifier is making a wrong determination, please raise a support issue so that we can improve the classification for a future release.