Aug 26

The first part of a series of posts on Grails and Hudson leading up to a presentation at the London Groovy & Grails User Group. Subsequent instalments will include testing (unit, integration, functional), test coverage, automatic war deployment and monitoring Hudson with Opsview Enterprise.

Grails has a rich plugin eco-system with over 400 hundred plugins – so it’s easy to miss something useful. If you’re serious about software craftsmanship, then using static code analysis tools should be part of your quality regime as it gives further insight into the code base (and if you insist, yes it’ll help with your Technical Debt management).

CodeNarc provides static code analysis for Groovy and the CodeNarc plugin for Grails allows you to perform this analysis with the “grails codenarc” script. Behind the scenes this uses the CodeNarc ant task and settings from grails-app/conf/Config.groovy and produces an HTML report by default.

Until recently, if you used the codenarc target within a continuous integration server such as Hudson – then the HTML report would be generated and sit in the workspace waiting for a diligent developer to check it. You can imagine how often that happens in practice with all the other demands of a project!

However, I’ve now integrated the CodeNarc XML output with the Hudson Violations plugin so that an overview trend line is shown against the Hudson job. Then the team quickly fixed the violations…

You can also get a breakdown by priority:

And in-context views of the violations so you know what to fix:

This is how you do it…

Grails config.groovy codenarc { reportName = 'target/test-reports/CodeNarcReport.xml' reportType = 'xml' // any further settings like maxPriority1Violations=0 }

Hudson

Set up your Grails build step – normally you’d add the ‘codenarc’ target:

The codenarc.properties file can be used to configure specific exclusions, the location of this file can be passed in as a system property (shown above).

You need to have installed the violations plugin (Manage Hudson > Manage Plugins > Available and search for Violations). As this is a recent addition, I’m using a patched version of the Violations plugin, though the patch has been integrated into trunk (I’ll update when it is released). Configure violations:

Note the ‘Faux project path’ – you may need to set this to get an in-context view working properly due to path (e.g. if your code is checked out to workspace/trunk)

I also had a contribution to CodeNarc accepted at the weekend to add aninlineXml report type – this will, with a minor tweak to the CodeNarc parser, allow the Hudson Violations plugin to give the rule description on the pop-up message.

3 Responses to “Grails & Hudson Part 1: CodeNarc”

  1. avatar Steven Sproat says:

    Thanks for this write-up — I’ve got CodeNarc integrated into our Hudson system now. I had to use the latest snapshot violations plugin due to the parsing error with 0.7.7.

    However, I can’t get the in-context view working. My source code exists in the Hudson workspace, so I shouldn’t have to mess around with the faux project path. I am already using the JSLint XML violations, and the in-context preview works there. I’m wondering if it’s the “package”

    What did you use for your faux path? I feel without the in-context view that the usefullness of the violations is lost, except for viewing the numbers of violations over time.

    I noticed in the violations.xml” file in the build directory, that my CodeNarc element’s elements look like:

    whereas my jsLint elements refer to the files by the full path.

    Thanks.

  2. Hi Steven,

    Probably best to discuss over at http://leanjavaengineering.wordpress.com

    Your violations.xml fragment for CodeNarc didn’t come out in the comment but to answer your question I’ve looked at the job configuration for my London GGUG talk. I generally run Hudson/Jenkins on Linux, but on that Windows 7 laptop the code was checked out from Subversion to ‘trunk’ under the GGUG_trunk\workspace (this is no longer the default Subversion setting for ‘Local module directory’) within ~\.hudson\jobs – so in that case I had the faux project set to the absolute path: C:\Users\rbramley\.hudson\jobs\GGUG_trunk\workspace\trunk

    Hope this helps,

    Robin

  3. avatar Fletch says:

    Thanks for this. But don’t use target/test-reports to store the reports because if you have a test-app build step also writing to this directory, it wipes the CodeNarc reports before the violation data gets calculated.

    Check out http://www.saltwebsites.com/2011/grails-codenarc-jenkins-integration for further info.

Leave a Reply

Nagios © 1999-2011 Nagios Enterprises LLC. Nagios, the Nagios logo, and Nagios graphics are the servicemarks,
trademarks, or registered trademarks owned by Nagios Enterprises, LLC. All Rights Reserved.
Opsview © 2008-2011 Opsera Ltd. Opsview, the Opsview Logo, and Opsview graphics are the
trademarks or registered trademarks owned by Opsera Limited. All Rights Reserved.
preload preload preload