Sync changes from master to gh-pages on each merge request

[cdrage]

This adds the functionality for Travis to sync with http://kompose.io in
regards to "syncing" the docs directory in master and the docs within
gh-pages.

Two things are added:
script/sync-docs/sh
script/deploy_key.enc

The encrypted key follows the conventions here:
https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
and the functionality of running: travis encrypt-file encrypt_key

The script is ran each-time a PR is merged (and only if it's
sucessful!) as per the modifications in .travis.yml.

Thus each time we make a change in master, there's no need to open up
another PR for syncing the changes with gh-pages.

[cdrage]

This is a WORK IN PROGRESS and is open in order to track current work and test the integration with Travis CI.

Up for review now!

No, this will not 100% work. I still need to fully test this.

[cdrage]

ping @containscafeine @kadel and whoever-else-wants-to-do-a-quick-review

I tested this at https://github.com/cdrage/kompose/ and it seems to work.

Only way to test this on the Kompose repo is to have it merged in and then merge a change to a doc.

This only runs the doc sync on 1.6 of Go (so it only runs once!)

[concaf]

nit:
How about -
script/sync-docs.sh in place of cd script && ./sync-docs.sh

[kadel]

I guess that this is because of path DOCS_KEY.

I agree with @containscafeine it is not nice to do cd ;-)
How about changing DOCS_KEY to script/deploy_key and run it like script/sync-docs.sh?

[cdrage]

@containscafeine @kadel

Only reason why I do this is to make sure that the cd kompose and cd .. work correctly so there is absolutely no way to accident push to master by accident or mess with the root directory!

But I can change it so we can simply do ./sync-docs. Its much cleaner!

[kadel]

if you think it will be safer like this, than i'm ok with it.

Maybe just one thing to consider: If another command is added to list after cd script && ./sync-docs.sh what is its cwd going to be? ./script/ or it will remain as before?

[cdrage]

@kadel
I updated it to do just ./script/sync-docs.sh way better now!

[cdrage]

Note:

I'm avoiding using: https://docs.travis-ci.com/user/deployment/pages/ since it won't sync between the master branch and gh-pages. Also, since it's unable to run pre_run and post_run scripts (so we can update the docs!)

[cdrage]

Had some issues with replication / travis that may help for review:

To replicate:

(following: gist.github.com/domenic/ec8b0fc8ab45f39403dd)

!!! Edit /scripts/syncdocs.sh to match your fork for $DOCS_REPO_URL !!!

1. Create a new SSH key: ssh-keygen -t rsa -b 4096 -C "[email protected]". Add the public key to GitHub.
2. Copy the private key to the fork directory (with this PR applied as a patch) with the name deploy_key
3. Use the travis client gem install travis and run command travis encrypt-file deploy_key -r YOURUSERNAME/kompose !! important. forgetting -r wont add the values to travis-ci.org
4. Using the above output from the travis client, replace the iv / key values in /script/syncdocs.sh.
5. Remove deploy_key and make sure your deploy_key.enc is in the /script/ directory.
6. Push the changes to your master branch
7. Open up a PR with changes to a /docs file and merge it.
8. Travis should then run the build and sync between the /docs/ folder in master and gh-pages
9. Wait patiently for the build to complete and look at your gh-pages branch.

[cdrage]

@kadel @containscafeine

I can confirm that it works at https://github.com/cdrage/kompose/tree/gh-pages

I don't think there's any harm to merge this in and test it with a documentation update! Should we try it?

[kadel]

What key are you using?
Is it tied to you account? Shouldn't we use special user for this?

[cdrage]

@kadel

Yes, it's a new SSH key that's been generated that's tied to my personal account.

We could use this key temporarily untill...

We create a secondary user / "bot" and use it for SSH, although we would have to go through the process of getting it into kubernetes-incubator / invited by an administrator.

[kadel]

This is something that I'm a little bit afraid of. That ssh key will have access to all your repositories. But it is your user account so if you are OK with it .... 😉

It looks like we can add new users to Kompose repo without adding them to kubernetes-incubator group.
I just tested it with @surajnarwade ;-)
We could create kompose-bot user and use that instead.

[kompose-bot]

@kadel Hello world! I'm @cdrage 's bot :) Add me!

[cdrage]

@kadel

I've gone ahead and created @komposebot

I've also updated the deploy_key as well as the bash values. :)

So it's all good-to-go now!

[kadel]

lets test it than ;-)