A Change to Travis

So immediately after getting out that post earlier, I then found a slightly better way of doing everything so that my .travis.yml is clean and neat. With this new method, thanks to Maxime Kjaer ¹, I’ve not only got the scripts split out from my .travis.yml, I also have it now proofing my generated HTML. The added benefit of proofing my HTML on Travis means that now misformed code won’t get automatically deployed to my droplet and then require me to manually go into the changes and resolve the issue on my server.

After modifying the scripts used in his post for some of the tweaks I use that he doesn’t (using rsync instead of git, differences in key storage), I’ve now got a much cleaner Travis-CI log. Not only do I have a cleaner log, I also have better markdown verification as well as a warning in case I typo’d a outbound link before it gets published.

Here’s what my new .travis.yml looks like:

language: ruby
cache: bundler
rvm:
- 2.2.0
branches:
  only:
  - master
env:
  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
addons:
  ssh_known_hosts: sfo.plttn.me
before_install:
  - bash _scripts/install.sh
script:
  - bash _scripts/build.sh
  - bash _scripts/test.sh
after_success:
  - bash _scripts/deploy.sh

For the scripts, build.sh is the generic one line command, but install/test/deploy are all slightly different based on the constraints that I have.

The install.sh script however is the thing that gets my SSH key out of environment variables and gets it loaded so the worker can rsync to my server.

#!/bin/bash

echo -e "$DEPLOY_PRIVATE_KEY" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
eval `ssh-agent -s`
ssh-add ~/.ssh/id_rsa

The build.sh script now handles both the re-integration of any stashed posts and the build of the site.

#!/bin/bash

bundle exec octopress integrate
bundle exec jekyll build

The test.sh script is modified from how I originally started it, as the pixyll head defines canonical URLs as absolute links, which means that html-proofer will attempt to hit the server to check if that page exists. Because that page hasn’t been deployed yet, it will fail. The option offered by the maintainer of html-proofer is to use relative canonical URLs, but that is not considered best practice by Google. With that in mind, my test.sh script has an extra flag included to treat all references to absolute domains as relative URLs when proofing. Thanks to Kristian Glass² for giving a easy solution.

#!/bin/bash

timeout 30s bundle exec htmlproof _site --only-4xx --external_only --check-html --check-favicon --href-swap ".*plttn.me/:/"

With all of this set up the way it is, my site will be integrated if necessary, built, have it’s HTML proofed, and then deployed to my server in the span of about a minute.