Download the code from GitHub : Current version 1.0.0
This plugin is now available on the Jenkins update center, so can be installed through the Jenkins plugin manager.
JSLint plugin for Jenkins
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:
- 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 did I get it?
Head over to https://github.com/boxuk/jslint-jenkins-plugin to get the plugin, and clone away!
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.
You can then install this plugin by going to the plugin manager in Jenkins and uploading it:
You can then go and set up a job like so:
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.