Download the code from GitHub : Current version 1.0.0
Update 04/01/2013
This plugin is now available on the Jenkins update center, so can be installed through the Jenkins plugin manager.
JSLint plugin for Jenkins
Coding standards are essential at Box UK. We use JSLint to check our JavaScript in all non-legacy projects (and have even added it to some legacy projects where the scale was not prohibitive). We’re all about automation here, so here’s how we went about getting JSLint into our builds!
Initially we started out running JSLint on commit, but there are several reasons we switched to running lint in Continuous Integration (CI):
- Having JSLint run as part of a CI job alongside our other checks makes it easier to track quality progress, particularly on legacy projects.
- We work on lots of projects and don’t want to have to set up the hooks on every single repo.
- We use Git for newer projects so any repo hooks we build for Subversion would have to be recreated for Git.
First steps in Jenkins
The backbone of our production floor is the Jenkins CI Server – every project has at least one job that runs on commit. Therefore, early on in our journey into automation, we started linting Amaxus 4. All we did was run a shell script that triggered Rhino and output to the regular console log. We then used Jenkins text finder to scan the logs and see whether JSLint had returned a clean bill of health. If not, the build was marked as “Unstable”.
Well, this was working, but only for Amaxus, and here came problem set #2:
- It wasn’t transferable to other projects.
- It was clumsy – devs had to read the console logs to find the failing lines. I ended up being “build monkey” a lot of the time, going through other people’s build logs to tell them why we had a red build on the wall.
- We couldn’t track progress over time.
- All our build slaves needed Rhino installed
Looking for options
We’d made progress, but we didn’t feel it was easy enough to integrate JSLint into a build. So, we looked at options:
- Violations plugin: this initially looked good – it takes JSLint output, presumably the raw console output. However, we didn’t go with it because we’d still need some way of running JSLint. Because we have to be able to run Rhino or Node, this meant our slaves would have extra dependencies in their Puppet manifests.
- JSLint4Java.jar via Ant: this looked promising but it required Java on the slaves. Furthermore, our version of JSLint is slightly modified from the “official” Douglas Crockford version, and I couldn’t find an easy way to specify our in-house JSLint fork.
Building a plugin
We’d made a few plugins for Jenkins – particularly our Amaxus plugin which allows us to set up a customer’s CI process including PHPMd, JSLint, PHPCodeSniffer and PHPUnit in less than a minute. It seemed logical to build a Jenkins plugin that produced logs that we could integrate into the build results. I toyed with the idea of JUnit format output but then plumped for a Checkstyle format – after all, this isn’t a unit test.
Firstly, our modified version of JSLint outputs to Checkstyle format. There were some difficulties with this initially that we had to overcome:
- Our early versions of the plugin required Rhino to be on the box. This wasn’t really acceptable as it added a dependency. Thankfully, you can bundle it into the pom.xml. This however had a knock-on effect that our jslint.js no longer worked – when not being run from the command line, Rhino doesn’t have readFile, writeFile or print functions available. Thankfully, it was relatively easy to add wrappers that call equivalent Java functions – we just added them to our JavaScript file. Perhaps not the most elegant solution, but it doesn’t introduce dependencies outside Java.
- While the plugin worked fine on a single Jenkins instance, once we started to run it in a master/slave configuration it threw exceptions saying it couldn’t serialise the builder. This was fixed by using the launcher and extracting our LintRunner functionality into a Callable class. See this Stack Overflow thread for more info.
Up and running
So, here is our plugin’s results page. We’ve found it really useful to have the information right there in the build report!
How do I get the JSLint plugin for Jenkins?
Step 1 – Get the GitHub code
Head over to https://github.com/boxuk/jslint-jenkins-plugin to get the plugin, and clone away!
Step 2 – Output an .hpi file
You’ll need Apache Maven installed to build it. Just type “mvn” in the project root and it will output an .hpi file in the target directory.
Step 3 – Install the plugin
You can then install this plugin by going to the plugin manager in Jenkins and uploading it:
Step 4 – Set up a job
You can then go and set up a job like so:
What’s next?
As mentioned earlier, we made a bunch of modifications to JSLint for our requirements. Since we did that, JSLint has been forked to the less opinionated JSHint so we might switch to that at some point.
Right now, this plugin is only set up with the JSLint options that constitute the Box UK JavaScript coding standard. The plugin should add options exposing the JSLint options. Maybe we’ll do it ourselves, but feel free to get involved on GitHub!
