Backend: Test That Site Builds With Travis CI

[harding]

This pull adds a control file for automatically test building the site in Travis CI. The pull also adds documentation and makes one minor change to the _config.yml file to prevent conflicting with Travis.

In addition to merging this pull, a Travis webhook needs to be installed. One of the core devs has already given Travis permission to toggle that hook, and I have sufficient permissions to tell Travis to enable it---so if this PR is ACKed, I will enable it before merging.

Once everything is enabled, all bitcoin/bitcoin.org branches will be test built and all PRs against bitcoin/bitcoin.org branches will also be test built. A message will be left on the PRs indicating whether or not they passed the test build and an icon at the top of our README.md will indicate the status of the master branch.

Preview

I've enabled this on my own fork of Bitcoin.org. You can see my build logs here.

You can test pull request building by creating a broken (or working) commit and opening a pull request for it to my master branch: https://github.com/harding/bitcoin.org

(Do whatever you want, just do me the favor of closing the PR when you're done testing.)

Notifications

By default, Travis docs say it notifies all organization members about failed builds. Since I don't want to spam the core devs, I've configured it to just email me. If anyone else wants to me emailed, leave a comment below before this gets merged and I'll add you. (Afterwards, just open a PR adding your email to the .travis.yml file.)

Interference With Core Development?

@theuni Please let me know if our using Travis in any way interferes with core development since we're part of the same GitHub organization.

Everyone else: Based on some quick responses I received in #bitcoin-dev, the main downside seems to be that travis-ci.org (the free version of Travis we're using) is limited to 5 concurrent builds from the same organization. When I configure Travis for Bitcoin.org, I'll set the maximum number of concurrent builds we use to one, so for the approximately 8 minutes it takes to build the site, we could (at worst) be holding up one Bitcoin Core PR.

Since we only handle a small number of PRs a day, I don't think this should be an issue, but opinions from core devs are welcome.

In addition, if the core team decides to use the paid version of Travis, someone should email me or @saivann. We'd have to discuss the actual amount, but we do have a small budget to pay our fair share.

[saivann]

I am all for enabling Travis too, thanks for your work on this!

[harding]

@saivann thanks!

Based on a suggestion @theuni made on IRC, I'll be enabling this at some point when I know @laanwj is around in case I mess up the queue or something. (If there are any significant problems, I'll immediately disable it.) I'll aim for around UTC noon on Thursday (unless there's critical feedback on this PR before then).

[harding]

Merged, and the merge commit was successfully built by Travis. (If you read this in the web UI, you can see the green checkmark next to the commit ID above.) Thanks to @laanwj and @sipa for being around in IRC in case I broke something. :-)

Any pull requests based on master from this point on should be automatically test built as long as they have the .travis.yml file in the top-level repository directory. If you want to skip building (e.g. because you only updated the README.md), put [ci skip] anywhere in your commit message.