Basic automation for publishing documentation

[errordeveloper]

This will build and upload docs on branch and tag pushes.

For each commits in any branch on upstream fork a documentation URL would look like:

http://docs.weave.works/weave/<branch>/<commit>/[index.html]

There will also be a pointer to latest commit:

http://docs.weave.works/weave/<branch>/[index.html]

For each tag there will be a shorter URL like:

http://docs.weave.works/weave/<tag>/[index.html]

I have manually uploaded latest_tag and v0.10.0.

After this is merged, the place to find latest development documentation is:
docs.weave.works/weave/master

[errordeveloper]

This is a very simple version which I'm happy with. I am thinking that it should be merged as is and other improvements can be done in a separate pull-request.

[rade]

Re the "Results"..., it shows

Installation Notes

• Using with boot2docker
• Using with systemd

In the absence of any other Installation items in the surrounding list, that does risk conveying the impression that these are the only two ways to install weave.

[errordeveloper]

In the absence of any other Installation items in the surrounding list, that does risk conveying the impression that these are the only two ways to install weave.

Good point! The purpose of this change though is just to make docs build on Travis.

[errordeveloper]

Any ideas what's up with coverage falling by -0.21%?

[tomwilkie]

I've only got one request: could you make the credentials a tarball? I ask because we will want to put more credentials in there in the future, and we can only have one with travis.

Also, can you have build-and-publish.sh print the URL the docs have been published please.

I wouldn't worry about coverage; are you rebased on master?

[errordeveloper]

I've only got one request: could you make the credentials a tarball? I ask because we will want to put more credentials in there in the future, and we can only have one with travis.

Didn't realise that it's only one file that can be encrypted... however I believe this cert can be used accessing all Google APIs, within that one project. Actually, I think that shell script that cats files into their destinations is neater then a tarball with a script that moves files around.

Also, can you have build-and-publish.sh print the URL the docs have been published please.

Sure, although I'd ultimately rather have it post a comment when it's a PR.

I wouldn't worry about coverage; are you rebased on master?

Yes.

[tomwilkie]

Actually, I think that shell script that cats files into their destinations is neater then a tarball with a script that moves files around.

Fair enough; I don't feel too strongly about this.

Sure, although I'd ultimately rather have it post a comment when it's a PR.

That would also be nice, although I don't know how you'd achieve it.

[errordeveloper]

@tomwilkie there some details I have discovered here.

When Travis tests a pull-request, the branch it's on is actually the target branch and with our URL schema the result of building docs on a pull-request made to master will end-up stored under master/<commit> (the commit hash actually will never appear in the tree, it's just how Travis pretends to merge).

There are more details to it, but basically the only thing I can think of is to trigger docs to build on push to master (and other whitelisted branches). For preview of pull-request I think we will need a different URL schema, one that would look something like docs.weave.works/<project>/pr-<N>-<commit>/.

[errordeveloper]

Ready to merge.

[errordeveloper]

Updated description and rebased.