I have posted more thoughts and tools on how to improve this here.
NOTE: The steps outlined are generally Linux/Mac centric, I don’t go into depth on Windows setup, but it shouldn’t be much different using Cygwin.
Why use CI?
Aside from the traditional benefits you see from your compiled code, there are some very compelling reasons:
- Automate versioning, combining, minifying, and gzipping files
- Run automated tests and get reports, keeping the codebase maintainable
- Run static analysis tools like the closure compiler or jshint
- Auto-deploy files (to S3, say) if our build passes
- Tag and other special stuff for release builds
- And that’s not all!TM We can also hook in Selenium tests, CSS Lint, and more
Not convinced? Tell me why in the comments.
Downloading and running Jenkins is incredibly easy. Just download Jenkins and run:
There are also native installers for most environments.
Now point your browser to
http://localhost:8080 to see it running.
Nailed it! Now we have a CI server!
1 2 3 4
1 2 3 4 5
To tell Jenkins where to find Gradle, we go to Manage Jenkins > Configure System from the top page. Add a name and enter your GRADLE_HOME (/usr/local/gradle if you followed the instructions above). It should look like this:
Setup a CI job
As an example, I’m going to use my stacktrace.js project on GitHub. Even though it’s a small JS library, almost all of the setup can be used for any type of project.
First, we want to install a few plugins that will help us out. We’ll need Git to pull down the code and Gradle to build it. You’ll want the Git, Gradle, and Violations plugins installed. It’s pretty easy to figure out, but hit up the Jenkins wiki if you get stuck.
We want to create a new job that runs analysis on our JS and runs our tests. Click New Job on the Jenkins sidebar and you’ll see the setup form.
Checking out and building a repo
Under Source Code Management choose Git and enter
master for the branch. It’ll look something like this:
For the Build section of the setup, we want to run the
minify build target from Gradle. You’ll also want to enter the location of the build file as
build.gradle. Don’t worry about the contents of our build script right now, I have a slew of blog posts in-progress that explain it. Stay tuned.
Now would be a good time to click Save at the bottom and then click Build Now on the sidebar for the job. You should see Jenkins checkout, pull down the latest Closure Compiler, and use it to minify stacktrace.js.
Running JS unit tests with PhantomJS
The days are past when you have to open a browser to see if your JS is generally working. PhantomJS is a headless WebKit browser that lets us interact with web pages (click links, pull from localStorage, etc.) without the browser window! This will let Jenkins run a browser with our tests and report the result. To follow along with the example, download and install PhantomJS in
/usr/local/bin (on Mac OS I just
sudo ln -s /Applications/phantomjs.app/Contents/MacOS/phantomjs /usr/local/bin/phantomjs). Note that if you’re running Jenkins on a headless server, you’ll want to have xvfb.
We also need to update the Build part of the configuration by telling gradle to run the
Gradle is now setup to run the QUnit tests in the project, but we need to tell Jenkins where to find the test reports. Easy! I encourage you to check out the source of build.gradle if you want to know how this is setup. It’s really quite interesting.
Finding potential bugs with JSHint
1 2 3 4 5 6
Now we just need to tell Jenkins to run jshint as well as our tests and where to find the JSHint report. The gradle build puts it in
target/jshint.xml. It should look like this:
I have really loved my CI setup for my web projects as well as my JVM-based ones. Now you have the power to go build a cool CI system for your projects. You can read more of my thoughts on this from my notes from my pursuit of the perfect front-end build. Enjoy!