Use the build in travis deployment mechanism to deploy to GitHub pages.

[koffie]

In #8 the possibility to make the documentation visible on GitHub pages was added, however this was done using custom bash scripts. Travis also has a build in mechanism for deploying documentation to GitHub pages. This seems much cleaner and removes the need of deployment keys.

[koffie]

@mkoeppe Since you implemented the original mechanism I have a question for you:

Am I correct in assuming that you implemented it this way because you didn't know about the built in deployment mechanism of travis yet (because it possibly didn't even exist yet then)?
And would you support switching to this build in mechanism?

[koffie]

Ok, I looked a bit more into this. And it seems that the build in mechanism wants to have a GitHub authentication token that gives write acces to all your GitHub repositories!!! This looks nonsensical and insanely insecure to me.

[mkoeppe]

Yes, I think it is relatively new. And yes, I much prefer the method using ssh keys that I used, which gives more fine-grained access. (Just a few months ago there was a notice about a huge security hole involving the GitHub authentification token; at that time I was glad I didn't go that way.)

[koffie]

By the way, from looking at it at https://github.com/travis-ci/dpl/blob/master/lib/dpl/provider/pages.rb it seems that the reason it needs the authentification token is just because it uses git over https by default. If someone reading this here knows ruby then we could submit a pull request that just uses git over ssh if the token is not provided. But let's keep that for the future.

For the time being I have been playing around with travis a bit to get to understand how it works. And it does seem that there are two enhancements that I want to make to the current ssh key based setup in sage_sample.

1. Use travis script deployment https://docs.travis-ci.com/user/deployment/script/ . This saves us doing manual checks on wether we are on the right branch or doing a pull request. Because travis then does it for us. As a bonus we get notified with an error if deployment fails, which is much better then the silent behaviour right now.
2. Make the setup with the keys so that the key is stored in a separate branch called "travis_key". This is a little bit of extra work. But it solves the problem that if someone forks a project, that they then have to commit their encrypted key to the master branch in order to keep travis happy. But having to do this will create unneeded merge conflicts.

[mkoeppe]

I agree with 1. and 2.