Add Jekyll docs

[duffn]

This adds docs built with Jekyll and Just the Docs per #443. You can view this on my fork here: https://duffn.github.io/slack-ruby-client/.

This will build the root docs on each push to master and the versioned tagged docs on each new tag creation. Head docs will be at https://slack-ruby.github.io/slack-ruby-client/ and versions docs at https://slack-ruby.github.io/slack-ruby-client/version/vX.XX/`

Notes

• Will need to update the project's pages settings to look like this

• Will need to update with each tag:

  • slack-ruby/slack-ruby-client@master...duffn:slack-ruby-client:duffn/jekyll-docs?expand=1#diff-b4d68dc855
  • slack-ruby/slack-ruby-client@master...duffn:slack-ruby-client:duffn/jekyll-docs?expand=1#diff-f0cbba616c

• I haven't changed any doc content except when it fixed a broken link or removed some uncessary leading works in the case of adding the callout component like here: slack-ruby/slack-ruby-client@master...duffn:slack-ruby-client:duffn/jekyll-docs?expand=1#diff-36f22022d6 (was "Note that the")

• If you want to push up v2.1.0 docs, you can build them locally and push to the gh-pages branch or take what I've already built here: https://github.com/duffn/slack-ruby-client/tree/gh-pages/version/v2.1.0

• I've tested and proofread as much as possible, but there's bound to be something missing or broken which I can fix forward.

Closes #443

[duffn]

1. I used version because it was simplest to ensure that we don’t delete the versioned docs when deploying but can look into it without: https://github.com/slack-ruby/slack-ruby-client/pull/450/files#diff-9cf2000c53760d837a449f874e53f792819108d3a4bf346336d0f7d082deae2cR50
2. We could enumerate though would need to ensure we only get 2.1.0 and up because previous versions are ignored since they won’t have docs.

Let’s just keep the readme then. Though that was the reason I raised the issue before doing the work. The readme is definitely simpler to maintain. The site adds some “pizazz” but maybe not much more than that.

[dblock]

I don't dislike the pizazz, but it sounds like you don't feel strongly about it either?

In terms of pros we get easily linked old docs. That's a good thing. I think if we can automate the part where we update the stable release section to say "this is docs for version X" during build from tags, it would simplify releases, and therefore is quite valuable.

So what do you think about publishing the README without gutting it into new .md files into a new site? We would get old docs published by the same process by doing it once manually from tags.

[duffn]

I'd feel more strongly if there docs were larger like https://docs.metasploit.com/. But for these docs, I don't have a strong preference.

I'll take a look at the other ideas.

[duffn]

I think now I'm more inclined to just suggest adding links to different versions in the README in lieu of creating the docs site. They can be generated during the release process or just manually updated and added in the README.

#!/bin/bash

echo "## Versions"
for tag in $(git tag --sort="-refname"); do
  echo "- [$tag](https://github.com/slack-ruby/slack-ruby-client/blob/$tag/README.md)"
done

[dblock]

I am not sure we need a long list of versions. Latest feels good enough, no?

[duffn]

Sure, one or two seem fine - just showing how they could be generated.