automatic travis build take 2

[reimertz]

Sadly, due to the differences between how *.github.io and *.github.io/project are being built and served by github, our current repo isn't compatible with the automatic travis build that I implemented.

I propose that we rename this repo to opentracing.io, which will give os the ability to select which branch we want to use as our source for the static content. Github will also do a 301 from opentracing.github.io -> opentracing.io so there won't be any noticeable side-effects.

This would remove the need of running npm run production before each individual commit to master. That means no more changes in /documentation which is causing each commit to be huge at the moment.

Also, we'll be able to see if a PR is breaking the build or not which is nice. 😄

I would say this is a win-win.

[bhs]

... related to this, I'm going to propose (separately, and not today since I'm busy with something else) that we create something like github.com/opentracing/core which would provide a home for structured data that addresses #76 as well as future issues around core OpenTracing semantics. I guess we'd have to manually migrate existing open issues about OpenTracing semantics from the docs repo, but that would be a one-time thing.

[reimertz]

Okay, since no one had any opinions/remarks, I would say we should go with this for now. It would remove a lot of the hassles we currently have. :)

[bhs]

SGTM

[reimertz]

Can you then rename the repo so I can initiate the switch?

[bhs]

@reimertz done :)

I am going to do some hard-refreshes over the next 5m to make sure there are no problems, but seems good so far. At the first sign of trouble I will revert the rename, though. I think the 301 redirects are going to pave over any difficulties.

[reimertz]

I think we can close this ticket now, because everything seems to work flawlessly.