Continuous Integration, testing and staging

This round, we’re going to be getting Travis-CI talking to Github so that we can

1. Build the site on a vm
2. Run tests on vm
3. Upon success, save build to gh-pages branch
4. Push gh-pages branch to Github
5. Point DNS to Github Pages

To get started, sign up for an account at Travis-CI by linking your Github account. Then link your burdendotcc repository.

Continuous Integration

To begin most tasks, it’s usually good practice to branch from master.

$ git checkout -b ci

Update the Gemfile

gem "minima", "~> 2.0"
gem "html-proofer"

As you can see, We’ve adopted html-proofer for a basic test as per Jekyll’s recommendation. This thing checks HTML best practices, then verifies that images and links work. That will come in handy when we need to verify that all of our assets were compiled and linked correctly.

Update bundler

$ bundle install

Create a new file .travis.yml

language: ruby
rvm:
  - 2.4.2
script:
  - bundle exec jekyll build
  - bundle exec htmlproofer ./www
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

Note: When Travis builds our project, it saves gems in a vendor directory. Since we have our source files in src, there’s nothing to stress about.

Staging

So with regards to a work flow, we’re going to utilize Github’s Pull Request feature to trigger a build, then deploy to Github Pages for a stage. Some day we’ll use a merge to the master branch to trigger a production deploy, but that won’t be covered in this walkthrough.

First we need to setup a CNAME on the DNS server pointing to burden.github.io.

Next create a file named CNAME and save it in the src dir.

stage.burden.cc

Finally we must update _config.yml

include:
  - CNAME

Moving along, we need to generate a Personal Access Token from Github. The only scope needed is repo:publicrepo. _Be sure to note down the token, because you’ll only be shown that shit once and Travis is going to hide it from you later

Over in settings on Travis, set an environment variable.

It is critical to make sure that the Display value in build log toggle is set to Off!

GITHUB_API=<token>

While we’re in the settings let’s toggle off the Build pushed branches option, since that is not necessarily inline with our proposed workflow. No need to overwork Travis.

Finally we get to adding onto .travis.yml

after_success: |
  if [ -n "$GITHUB_API" ]; then
    cd "$TRAVIS_BUILD_DIR/www"
    git init
    git checkout --orphan gh-pages
    git add .
    git status
    git -c user.name='travis' -c user.email='auto@travis-ci.org' commit -m stage
    # Make sure to make the output quiet, or else the API token will leak!
    # This works because the API key can replace your password.
    git push -f -q https://burden:$GITHUB_API@github.com/burden/burdendotcc gh-pages &2>/dev/null
    cd "$TRAVIS_BUILD_DIR"
  fi

Let’s wrap things up with a quick push to our remote repo.

$ git add .
$ git commit -m "Adding ci post"
$ git push origin ci

At this point, all we need to get the build party started is a pull request on Github.

After you create your pull request, you can then scope out the action on the dashboard at travis-ci. If all goes well, you can then hit up your stage stage.burden.cc