Discover and Correct failure of #116

[relativityboy]

We want to be able to deploy our site with jekyll modules that are not supported by the gh-pages build process. The code created by #116 was intended to address this, but the gh build did not function as intended. We want to know why.

AC

• [x] find out why the rake task written for #116 failed and put that information in a comment on this issue with the title Results
• [x] optional - update the master and gh-pages branches such that we are able to run a rake task conforming to the requirements outlined in #116
• [x] do not exceed 5 points worth of effort for this issue.

[inertia186]

It seems like all of the existing documentation on how to do this is just out-of-date. So I took a step back and looked at other options. I've had some luck with this:

1. I cloned the steemit/devportal repo to inertia186/devportal.
2. jekyll build
3. mv _site docs
4. git add -A
5. git commit -a -m "manual build"
6. git push
7. Then, I changed the settings of the repo not to use gh-pages but instead use master/docs.

Looking at the api-definitions, they appear to have neatjson formats, but the CSS is messed up. I have high confidance that this will work in production.

[feruzm]

2. jekyll build --destination docs

[inertia186]

d1f65d2f09699f40460039e91352209a63d17578

[relativityboy]

Hrm. I'm not a fan without practice changes. I don't like us using a dir in master as our built code, not while we're using master as our "integration" branch. I want our .gitignore for most branches to include the deploy folder.

To proceed I suggest we move our default branch to be something like develop.... we branch and merge our issues on that, and merge develop into master only when it's time to release.

@inertia186 @feruzm @roboza. - input please.

[inertia186]

I think our hands are tied, somewhat, because github doesn't allow very many options for where pages are published. I agree with your suggestion.

[roboza]

I am good with the idea of a develop/staging branch and then when we are ready merge to master which will be "live" but as @inertia186 said, We will have to build outside of Github since they will not allow custom plugins. Not sure if we can get away without deploying to a folder in master.

[feruzm]

I don't mind also using develop instead of master and merge only when there is a release

[inertia186]

Results: I think the root cause of the #116 failure was that GitHub pages do not work the way most google searches lead one to believe. There may have been a time when a merging gh-pages with an existing _site already present did not kick off a new build. But I can imagine a scenario where people inadvertently include _site and wonder why it isn't doing a new build, and that was probably more common than people who wanted to do their own build.

I recommend switching todevelop to merge issues and master /docs for release.

[relativityboy]

I think we have a plan. I'll switch the default branch to develop and set the site to follow master