While developing the website for Hardy, it seemed obvious that I should be writing Hardy-based tests for it. What better way to figure out how to simplify testing than see what bits of the process were the hardest?
The site is hosted on GitHub using the gh-pages branch of the hardy.io project. I've played with various toolchains in GitHub pages in the past - csste.st uses Wintersmith, for example - but wanted to follow my own best practice suggestions and automate the process of getting an idea from inside my head, through the text editor, through a bunch of tests and out onto production as much as possible. The main Hardy project uses Travis CI to run unit and acceptance tests on every commit so it seemed obvious to use it for this. What I've ended up with is what I think is a nice, simple process. This is designed for sites hosted on GitHub Pages but is applicable to other sites run through Travis,
The manual steps of the process are:
- Make change in your website
masterbranch - Preview changes locally
- Commit changes and push to GitHub
After this, the automation takes over:
- Travis pulls latest commit
- Builds website project to
distfolder inmasterbranch - Launch web server on Travis
- Run Hardy tests against local web server
- On successful test run, push (via git) to
gh-pagesbranch
The full process is used to build hardy.io. Have a look at the .travis.yml, package.json and post_build.sh files mostly.
