What we're missing ATM is different documentation versions for different application versions. What this change does is that it's:
- finding out what is the current branch (e.g. 1.0.x)
- finding out out what is the name of the main adoc file (e.g. spring-cloud-sleuth)
- pulling the changes from gh-pages after checkout
- finding out what is the list of comma separated whitelisted branches (via the `docs.whitelisted.branches` prop)
- in gh-pages creating a folder with name of the branch (e.g. /1.0.x)
copying all the docs/target/generated-docs/ to that folder
- if the branch from which we're calling the script is NOT master then we're changing the ${main.adoc}.html to index.html so that it's easier to access the docs (e.g. http://cloud.spring.io/spring-cloud-sleuth/1.0.x/)
Using the e.g properties from Zipkin Consumer gives the following error when loading the zipkin-server ui:
ERROR: cannot load service names: zipkin/storage/mysql/internal/generated/tables/ZipkinAnnotations
ERROR: cannot load span names: zipkin/storage/mysql/internal/generated/tables/ZipkinSpans
So to fix it you have to explicitly add username and password for the mysql storage.
* Fix headers in messaging
with this change the span related headers are changed to be compatible with messaging specs. The change is backwards compatible so we accept the old ones as input, and as output we're producing both new and old headers.
fixes#332
* Re-added missing server side span
with this change
- HandlerInterceptor is responsible for wrapping requests in spans
- added Sring Data REST instrumentation
- added Zuul instrumentation
- it will not wrap error controller related requests with spans
- tests have been changed to ensure that ALWAYS there is at least one span on the server side (that way it will show up in Zipkin)
- "fallback" mechanism has been added that if a HandlerInterceptor hasn't been used then we are forcing creation of a Span at the server side
fixes#321
(cherry picked from commit 4f1ef52e6c)
