On Aug 18, 2009, at 2:08 PM, Gregory Boissinot wrote:
At the moment, the latest build is failed because Checkstyle
violations are
found.
The latest fail on Bamboo
http://bamboo.ci.codehaus.org/browse/GRADLE-CORETRUNK-15518/log
The latest fail on Teamcity
http://teamcity.jetbrains.com/viewLog.html?buildId=23560&buildTypeId=bt41&tab=buildLog
The latest fail on Hudson
http://code.taglab.com/hudson/job/Gradle/39/console
Due to violations, the test and integtest tasks are not executed.
I propose to not fail the build by default when there are violations.
The build status could be determined by thresholds on Gralde 'code-
quality'
plugin or by the CI server with a plugin.
For instance, there is the
violations plugin in Hudosn for this need.
What do you think about changing this behavior?
First of all there is the question why those changes made it into VCS?
The reason is that our developerBuild task does not depend on the
check task yet. Therefore my local build did not point out the problems.
But I see your point. In particular when we have more and more
checkstyle rules it might make sense not to be that strict. In fact we
could already customize the checkstyle task of the Gradle build
accordingly.
checkstyle.properties = someAntCheckstyleTaskProp: someValue
Thus we could set maxErrors and maxWarnings properties.
I will also have a look at the violations plugin. I guess a warning is
annoying enough for a thing like unused import. For a public API
method without javadoc it might make sense to have a failed build
though.
Let's wait for some more feedback. Then we can change the behavior.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
