Google Closure Compiler results parsed by Jenkins Warnings plugin

Context

In our team we wanted to have the warnings and errrors from the Google Closure Compiler running over our JavaScript application visualized and tracked by the CI build.

Solution

Luckily, there is the Warnings Plugin for Jenkins that is exactly for this purpose. But it lacks a parser that is capable of reading the results from this compiler. Yet it also comes with a script extension, which allows you to define your own little format.

Following the description for configuring your own parser in the system settings of Jenkins, it comes down to two important fields: The regular expression and the Groovy script to provide the warning descriptor.

Configuration

Regular Expression

^(.*):(\d+): (.+) - ((.*\n)+?)[ ]*\^\n$

This expression takes everything from the first line of an entry up to (including) the last line with the ^ that points to the error.

Mapping Script

import hudson.plugins.warnings.parser.Warning

String fileName = matcher.group(1)
String lineNumber = matcher.group(2)
String category = matcher.group(3)
String type = "Dynamic Parser"
String message = matcher.group(4)

return new Warning(fileName, Integer.parseInt(lineNumber), type, category, message)

The script is pretty much the same as the example script, since the groups from the regular expression match up with the expected sequence.

Limitations

• The first line in an entry does not always specify an 'abstract' message, often pieces of the actual code are included. It can thus not be used as the 'type'.
• Although some entries have several lines reported from the compiler, any display in Jenkins strips the new-line characters and presents the whole text in one line. (Replacing "\n" with a br HTML tag doesn't work)
• As a result of that, the line with the ^ is not part of the message to avoid confusion. I tried calculating the offset and then specify the ColumnPosition in the Warning, but it seems this property isn't considered for highlighting the source code.

Side Notes

• Since we're running a Grunt based build, we don't see any errors as these already cause Grunt to fail, failing the whole build. We use this to track the warnings only.
• Our build saves the compiler result in a text file that is analyzed by the plugin. Although not tested, the plugin should also be capable of analyzing the console output with that expression.