worklfow

[smnwndrr]

We should add css to .gitignore and instead css has to be build on server. How should we do this? With Travis-CI`

[smnwndrr]

We could think of not working on gh-pages. Since gulp, scss shouldn't be on production site. Instead we could write a worklfow for gulp to deploy to gh-pages. If we do this, we could have a worklfow like this:

1. develop on our own repository
2. create pull request to master branch on codeSessionsP2
3. Travis will run "gulp deploy"
4. tada: updated gh-pages, without any traces of gulp and sass...

[mxklb]

I think gulp-gh-pages is what we should use ..

[mxklb]

Besides I agree to your work-flow described above for the deployment. But instead of using travis we could trigger gulp maybe using git hooks and simply executing a script (gulp deploy) et voila .. this avoids additional dependency to travis and the gh-pages deployment process stays where it belongs to, just configured in github as a hook ;)

[smnwndrr]

Again I forgot to incorporate this issue in my commit messages:

Commits:

5cf097169b4d4cf50631588af0e62e199b5ebd51 04e99f5dc47e55398490af47cac92e20eb319a53 605b31e12489f006135dc72cdfa58834d6b9e8a5 04a2fe27b63a098fb6aaf34f7a14e5b355cca9af 9736ab16107157b796e14a5d169f1e747044dd07 b46d870c84de5edaaec29619c5ec1d08d5cd0696

now gulp has a two updates:

1. It compiles all files to one folder called dist
2. the new gulp-task: 'gulp deploy' pushes the dist folder directly to the gh-pages branch.

Todo:

• removal of dist folder from git
• automatic build via git hooks

[mxklb]

• the new gulp-task: 'gulp deploy' pushes the dist folder directly to the gh-pages branch

Does it really push it somewhere remote? I though it merges it from dist folder to gh-pages branch? Or do you mean by push'ing: Committing the modified dist folder version to the HEAD of the gh-pages branch?

Maybe doing a merge instead of a push from the dist folder to gh-pages may provide commit messages of the source changes to be propagated to the gh-pages branch? This is some kind of cosmetics, but would result in more human readable traceability what happened in gh-pages/production. Another idea would be to construct a commit message for pushing by combining all happened commits in the master branch since last deploy (some kind of change log). Nevertheless cosmetics ..

• Removal of dist folder from git should be simple done with a .gitignore entry
• Automatic build via git(hub) hook must be tested (tbd). I think calling a simple shell script coming out of our repo should succeed. But maybe due to project build dependencies (node, gulp) we may end up using travis ;)

Sorry, just thoughts. Actually I could not try it out, but I'll soon ...

[mxklb]

All right I reviewed your latest gulp deployment to the gh-pages branch. There is an option to set the commit message for the gh-pages commit (options.message). We should at least use this and set it to the latest commit message incl. the hash of the HEAD of the master branch to be the gh-pages commit message. So it's clear where the gh-pages HEAD comes from. Actually the default time stamp is ugly and really uninformative.

• And yes 'gulp deploy' pushes to the remote! Which is - I think - quite a bad idea. It should only deploy it to the local gh-pages branch, pushing to the remote shall be done done manually after local reviewing! We should look for solutions to gain this behaviour ..
• Another bad thing is: CNAME is not provided. We should at least switch to the gulp-gh-pages-cname fork or find another suitable solution.

Actually we're running a bit out of time and working on the workflow brakes us down in regard to productive development. Nevertheless these workflow gulp deployment gh-pages issues are essential for us in future, that's for sure. But I think we should actually leave them where we are ..

We should think about leaving out gulp-gh-pages deployment and simple step back deploying to gh-pages branch with all dev files. I think this is the way to go for now to finalize what we want to have at the beginning of January.

So please do all further development on the old base before gulp-gh-pages (1cc26e8). Simply checkout this and branch it for on going development. To pull in your small layout fixes (35866c3, 655c879, 524eded) git cherry-pick should do the job.

[mxklb]

We should beside the automated travis master branch deployment implement a gulp deploy task (as you already did) to directly push the actual branch's build artefacts folder to gh-pages manually. Doing so will provide a solution for pushing staging results of feature branches to personal gh-pages easily.

[mxklb]

I think we can close this issue now .. please do so if you confirm ..

[mxklb]

all in ..