Speed Up That Nokogiri Build

An important part of continuous integration is making sure that you can rebuild your environment from scratch. Unfortunately for most Rails apps, running 
bundle install
can cause your CI job to hang for several minutes, and nokogiri is usually the culprit.


Don't rebuild LibXML from scratch
The reason it takes so long to install nokogiri is that, by default, it will try to build its own copies of libxml and libxslt, which are huge. That definitely makes initial adoption easier, but now we're stuck with it, so let's speed things up a bit.

Fortunately, the nokogiri gem takes a build option that tells it to look for system-installed xml and xslt libraries. To get Bundler to use it, we create an entry in the local bundler config and then install it like so:


bundle config build.nokogiri --use-system-libraries
bundle install


Clean up after yaself
The trouble with this approach is that the bundle config is not ephemeral, and if you are running multiple builds on the same Jenkins server, the config will persist and affect other branches. I recommend sticking the following in your `test.sh` right after your gems are installed:


bundle config --delete build.nokogiri

Doing this for any specific gem build settings after you run `bundle install` will make sure that you do not get screwy environment behavior when running future builds.