Continuous Integration (CI) is a development practice where all the developers integrate their code into a shared repository as often as possible. Each change to this repo is then verified by an automated build, allowing teams to detect problems early.
Travis is an online tool to run this build and perform any tests you may have on every commit. It works with GitHub repos and it’s free for any open source projects.
In our case, Travis will build the Jekyll site and test the HTML on every commit, and then warn us if the build fails or if any of the links on the HTML are dead. It will even check external links!
This process will not affect your code in any way. It’s just an enhancement, an added test layer.
Setting up Travis
After it finishes syncing your data from GitHub you should be able to go to your profile and see all your public repos. Go ahead and switch on the repo for the Jekyll site you want use for this.
In order to let Travis build the site, we need to provide the required packages for the build, the same you would need to build it locally. In this case it means Jekyll and any other plugins you’re using.
To define these, create a filed called
Gemfile and put it on your repo root. Here’s an example for this site:
source "https://rubygems.org" gem "jekyll" gem "jekyll-redirect-from" gem "jekyll-paginate" gem "jekyll-sitemap" gem "jekyll-feed" gem "html-proofer"
This will allow Travis to install Jekyll and all the plugins you are using before running any tests. Remember that you can find what plugins you are using on your
_config.yml file. Notice I’ve included
html-proofer too. This will check your compiled HTML.
Important: Make sure you add
vendor to your excludes list in your
_config.yml file, so Jekyll doesn’t compile the dependencies as part of the site, therefore slowing down the process.
Then we have to set a list of commands for Travis to run. By convention you should have a
script folder with a file called
cibuild on your repo root.
#!/usr/bin/env bash set -e # halt script on error bundle exec jekyll build bundle exec htmlproofer ./_site
Now we need to set up the Travis configuration. This is done with a
.travis.yml file in your repo root. We need to say what we are using and on what branches it should act, plus some enhancements. Here’s mine:
language: ruby rvm: - 2.1 before_script: - chmod +x ./script/cibuild # or do this locally and commit # Assume bundler is being used, therefore # the `install` step will run `bundle install` by default. script: ./script/cibuild # branch whitelist, only for GitHub Pages branches: only: - master env: global: - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer sudo: false # route your build to the container-based infrastructure for a faster build
Here we are telling Travis that this is built on Ruby, and to run the scripts in
./script/cibuild. It will run
bundle install first, which will go through your
Gemfile and install all the dependencies we set before.
It is important that you list all the branches you want to check. This site is an GitHub account site, not a project one, that’s why I’m running it on
master branch. Usually you’ll want to change that to
gh-pages and add any other temporary branches you may work on.
After you commit all these files, every further commit you make will trigger a Travis build. You can see a full log on the Travis website and see it happening in real time, check a list of builds and see where they failed, etc. Check out jaicab.com on Travis as an example.
But the beauty of CI resides in letting it run in the background. Then if the Jekyll build or the
html-proofer fails, Travis will email you with the problem. When you fix it, it will email you to confirm you it’s fixed. But as long as everything is alright, it will just double-check stuff for you.
You can also trigger Travis tests manually in the project page. This may be useful if don’t need to make any changes but want to double check all the external links you’re pointing to still work just fine.
The great thing about this is that now you will always have a stable codebase and no links to sites that are down, and this is tested on every change you make without any hassle.
If you want to go even further, I’d recommend having your Jekyll codebase on a
dev branch and make Travis test first and then deploy to the
gh-pages branch only when the tests passed.
npm and test that all dependencies are up and you could even write and run specific tests for your project. Welcome to the world of continuous integration. Let computers do the boring bit for you.