[GRADLE-2888] Fail build on Checkstyle Warning Violation Created: 16/Sep/13  Updated: 17/Nov/16  Resolved: 17/Nov/16

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Task
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 8



Java 1.7u40
Gradle 1.7

I was wondering how I might fail a build if there are any checkstyle failures? Currently I have this block defined in my build.gradle:

checkstyle {
ignoreFailures = false

Unfortunately, that only works on Checkstyle errors. I notice in the Ant configuration one can set a property to fail if warnings are above a certain threshold [Checkstyle Ant]([1]http://checkstyle.sourceforge.net/ant...), specifically the maxWarnings property. I'm not sure how to do this on Gradle!

Any help would be greatly appreciated!

Thank you.

[1] http://checkstyle.sourceforge.net/anttask.html

Comment by Joseph Earl [ 05/Jun/15 ]

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
Comment by David Byron [ 13/Nov/15 ]

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")
Comment by Janne Hyötylä [ 10/Jun/16 ]

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
Comment by David Byron [ 10/Jun/16 ]

I'd love a failOnWarnings property.

Comment by Juan Martín Sotuyo Dodero [ 29/Jun/16 ]

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.

Comment by Juan Martín Sotuyo Dodero [ 29/Jun/16 ]

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.

Comment by Janne Hyötylä [ 09/Jul/16 ]

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.

Comment by Juan Martín Sotuyo Dodero [ 10/Jul/16 ]

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.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Eric Wendelin [ 17/Nov/16 ]

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

Generated at Wed Jun 30 12:34:09 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.