Last year, I wrote a post on automating the generation of my static-site blog. As they do, things have since changed, and I figured I’d update accordingly.
Travis recently made several updates, many of which make our job easier.
Travis now has the option to build only if a .travis.yml file is present. Before, you needed a .travis.yml file in both your source and your display branch. Now, that’s no longer the case.
There’s also the ability to auto-cancel queued builds that haven’t yet started and only build the latest push or pull request. While this ought to have limited use on a blog (unless you’re like me and find or think of things immediately after pushing a commit), it’s still a neat feature.
Okay, that sounds bad out of context, but it’s actually a good thing. Before, the key needed for Travis to push the built content to production had to be in the .travis.yml file. While it was encrypted, it still wasn’t really good practice. That’s no longer an issue, because Travis now has an “Environment Variables” section.
So, where you would have set up that key, you now just take the key and set it in the Travis dashboard, using the same variable name. Yay! No more keys in the repo!
Another update precludes the need for the
ghp-import script in the Makefile, and renders this entire section moot.
script section simplifies slightly and we add a
This new section is particularly cool, because it supports a ton of different platforms, so you’re no longer bound to Github. You can declaratively deploy to almost anywhere, simply by changing the
provider and updating the options accordingly.
For more information, be sure to check out the documentation.
The main change to the config is with the Markdown plugin.
We went from this:
While it looks more complicated, it’s a lot more expressive.