CloudFront Invalidation, re-encrypt credentials for rust-lang

[edunham]

Also organize and document the .travis.yml

Had to re-encrypt the secret access key as well because Travis has a key pair per repo and it was previously encrypted using the key that went with edunham/rust-www (hence why it worked when I tested it from my fork). Duh.

Unfortunately https://github.com/laurilehmijoki/cf-s3-invalidator was the closest thing I could find to the rather intricate invalidation API process being solved for Ruby (it's preferable to use a Ruby invalidator because Travis is already spinning up a Ruby environment since the site is Jekyll). The gem may still work; according to the afforementioned docs the last breaking changes to the invalidation POST API were in May 2012 and the gem was last touched in August 2012.

I'll have another PR after this lands to add a timestamp of when the site was last generated to the error page -- that change will be useful for debugging invalidations, and its landing will test whether the changes in this PR do what they should. I'm especially interested in double checking that Travis builds only on merge, rather than on PR creation.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Looks like travis failed :(

[edunham]

Failing to decrypt on PR is a security feature in case malicious PRs try to expose the encrypted variables -- http://docs.travis-ci.com/user/pull-requests/

I'm consulting Travis resources to see if there's a way to completely disable building on PRs -- the docs made it sound like the branches.only setting was supposed to make it build only on master, but it's obviously still building on PR. If disabling build-on-PR is unsupported, I'll update the .travis.yml to only attempt decrypting any credentials if the commit was actually to master.

[edunham]

I've disabled builds on PRs in the web interface. Turns out there isn't a config file setting, but there is one in the UI.

[alexcrichton]

Would it be possible to avoid these commands on PRs? We may want travis to do something like jslint one day, and we do this on other projects as well

[steveklabnik]

It's unfortunate http://docs.travis-ci.com/user/deployment/ doesn't include cloudflare.

You can make it work by making a bash script that travis calls and checking the TRAVIS_PR env var or something like this: https://github.com/steveklabnik/automatically_update_github_pages_with_travis_example/blob/master/.travis.yml#L11

[edunham]

@alexcrichton Yeah, the alternative is to build on PR but execute the decryption logic conditionally. I'll update the .travis.yml.

@steveklabnik Minor nitpick; this is cloud_front_ not cloud_flare_ (getting mixed up is practically obligatory in talking about any of it, though) The docs you link do discuss s3 deployment, which is part of what we're doing here -- the cloudfront interaction is to invalidate cached copies of the site once it's rebuilt and deployed to S3.

[steveklabnik]

Ah ha!

[edunham]

r? @alexcrichton

Added conditionals so it's currently inert on PRs, but we could easily add test steps that run on PRs if needed. AFAIK the way to test that I got the encryption steps right is to merge and see whether it builds 😞

[alexcrichton]

This was TRAVIS_PULL_REQUEST above, perhaps a typo here?

[alexcrichton]

r=me with perhaps a minor typo or not, feel free to merge with it fixed and send future PRs to see if this works. I can also enable travis for the repo if necessary