Flooding your Outlook: Checkstyle and CruiseControl trimming

Its annoying when I receive emails of 10mb unless the attachments are mp3s sent by friends, all of which are backups to my originals, ofcourse.

Recently, I flooded my Outlook client with a dozen of automated emails from our continuous integration server, CruiseControl. The culprit – I had recently integrated Checkstyle, a tooling report that performs code checking and ensures that the java code adheres to various standards, as defined by Sun. Some of these include checking for javadocs on all public methods, providing getters and setters for private variables (I’d rather refrain from saying private members 😉 ), checking for unused imports, checking for a newline character at the end of a java file, among others. The CruiseControl build notification contained the Checkstyle report in html format, having thousands of code violation messages and this caused the email size to blow up to 10mb.

CruiseControl is driven from a config.xml and the integration with Checkstyle must be specified in this configuration file. In particular, the entry:

I removed the checkstyle entry to note the effects. What happened was that my email size changed from 10mb to 5mb. Still, 5mb is hefty. I took a look at the email report and it still seemed to have all the checkstyle violations.

What was happening was a duplication of the error report in my email that occurred when specifying:

It seems like CruiseControl was already printing out the system out to the build report. In addition, the above merge log entry was creating a pretty print of the violations as well.

Ok, so what about shrinking down the report?…We had thousands of Checkstyle violations, some of which were erroneous to our project. Checkstyle grants flexibility in choosing which checks to perform through the use of a config attribute inside of the <checkstyle> ANT task.
<checkstyle config=”checks.xml” failonviolation=”false”>
Our checks.xml defines the various code checks to look for. We decided the <designforextension> check wasn’t needed and this was clogging our log file, since most of our subclasses weren’t declaring public nonstatic methods as final.

Down to 4mb. ekh…

Back to CruiseControl’s config.xml. I read that config.xml email publisher is smaller than the htmlemail publisher. However, since I was still using the logdir attribute, the email size was still large and still seemed to have html formatting. I ended up removing the logdir attribute within my publisher so that the email now contains no information, other than the following:

Subject: [CruiseControl Build] fvt_framework Build Failed
Body:
View results here -> link://buildserver/buildresults/fvt_framework?log=log20081020130129

No more pretty emails for us