To workaround this you can use something like:

def checkstyleWarningsFile = 'build/reports/checkstyle/checkstyle.xml'

task verifyNoCheckstyleWarnings(type: GradleBuild) {
    doLast {
        File warningsFile = file(checkstyleWarningsFile)
        if (warningsFile.exists() && warningsFile.text.contains("<error ")) {
            throw new GradleException("There were checkstyle warnings! For more info check $warningsFile")
        }
    }
}

checkstyleMain.finalizedBy verifyNoCheckstyleWarnings

The above didn't quite work for me...but was super helpful. Here's what I ended up with:

   tasks.withType(Checkstyle).each { checkstyleTask ->
       checkstyleTask.doLast {
           reports.all { report ->
               def outputFile = report.destination
               if (outputFile.exists() && outputFile.text.contains("<error ")) {
                   outputs.upToDateWhen { false }
                   throw new GradleException("There were checkstyle warnings! For more info check $outputFile")
               }
           }
       }
   }

I'd like to add this properly to the plugin.

What would be the preferred option?

• Adding maxErrors and maxWarnings properties as in the original Ant task (or maybe just maxWarnings, leaving maxErrors at 0)
• Adding a failOnWarnings property

I'd love a failOnWarnings property.

Bare in mind that, having maxWarnings higher than 0 also means the failure property is not set, and therefore the log message stating checkstyle errors were found and printing to stdout the path to the report won't work as expected even without ignoreFailures = false

It seems to me that we can't relay this on checkstyle, and should probably test de report contents on gradle side to have the expected (and coherent with other plugins) results.

I'm willing to send a PR for this myself if given a green light.

Just to be clear, what I propose (and I'm willing to code) is:

• add `maxErrors` and `maxWarnings` to both the task and the extension, defaulting both to 0 (currently they are 0 for errors, MAX_INT for warnings). This will make sure that ignoreFailures to behave as other code quality plugins, failing the build if there are any lint errors of any severity. This does break backwards compatibility, but should not be an issue.
• manually parse the report XML in search of "<error />" tags, and if any one is found, display the Checkstyle error and path to the report file.

I would not go with a failOnWarnings property, since that would be inconsistent with other code quality plugins.

There is already a ignoreFailures option here and in other code quality plugins. How about introducing a new option 'ignoreWarnings' with default 'true'? This would retain backwards compatibility and would be similar to the already existing option.

I'm no fan of such option. Such option is not present in any other quality plugin, nor part of Checkstyle itself, so it's alien to everyone. I'd rather just expose the existing checstyle options `maxErrors` and `maxWarnings` to Gradle, which is much more flexible and just what an advancecd Checkstyle user would expect to have.

If you want to keep backwards compatibility, just default `maxWarnings` to `MAX_INT` as it's currenty in Checkstyle. This is a tradeoff between advanced Checkstyle users that know of this option and expect warnings not to produce a failure, and Gradle users that expect no build to succeed when any rule violation is found. I'm personally on the side of keeping line with Gradle, but that's minor, and both would solve the current issue.

You still need to parse the XML report manually for "<error />" tags to display the "Checkstyle rule violations were found." message regardless of the chosen solution.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Moved to https://github.com/gradle/gradle/issues/881