This round, we’re going to be getting Travis-CI talking to Github so that we can
- Build the site on a vm
- Run tests on vm
- Upon success, save build to gh-pages branch
- Push gh-pages branch to Github
- Point DNS to Github Pages
To get started, sign up for an account at Travis-CI by linking your Github account. Then link your
To begin most tasks, it’s usually good practice to branch from master.
$ git checkout -b ci
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.
$ bundle install
Create a new file
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.
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
Next create a file named
CNAME and save it in the
Finally we must update
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
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
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 email@example.com' 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.