Simplify server config; compile prestart

[harlantwood]

(Hopefully) simplified and improved the npm / heroku setup.

Notes:

• Heroku will run "npm start" if no Procfile is present
• set -e means that if any command fails, execution stops (app fails to start)
• Add less to dev dependencies
• Move asset compilation to bin/compile
• Added rm -rf app/assets/libs because repeated bower install (on my machine at least) caused errors

Upshot: everything should work the same as before, except that npm start now runs bower install instead of the Procfile doing it. lessc should now work on Heroku, which it was not for me previously.

[willzeng]

Thanks for getting started on this @harlantwood

I've pushed this branch to a test over at http://graphdocs-test.herokuapp.com/ and am getting an application error even though the build seems to have succeeded without errors. The logs currently show:

May 14 12:06:54 graphdocs-test app/web.1:  bin/compile: line 5: node_modules/.bin/lessc: No such file or directory 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! Linux 3.13.0-49-generic 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! code ELIFECYCLE 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! graphdocs@0.0.0 prestart: `rm -rf app/assets/libs && bower install && bin/compile` 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! Exit status 1 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR!  
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! Failed at the graphdocs@0.0.0 prestart script 'rm -rf app/assets/libs && bower install && bin/compile'. 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! This is most likely a problem with the graphdocs package, 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! not with npm itself. 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! Tell the author that this fails on your system: 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR!     rm -rf app/assets/libs && bower install && bin/compile 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! You can get their info via: 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR!     npm owner ls graphdocs 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! There is likely additional logging output above. 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! argv "/app/.heroku/node/bin/node" "/app/.heroku/node/bin/npm" "start" 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! node v0.12.3 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! npm  v2.9.1 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR! Please include the following file with any support request: 
May 14 12:06:54 graphdocs-test app/web.1:  npm ERR!     /app/npm-debug.log

I'm not sure why the lessc file is missing from there.

[harlantwood]

Because less and require.js are in devDependencues, you need to do:

heroku config:set NPM_CONFIG_PRODUCTION=false

Maybe we should add this to a deployment section of the readme.

[harlantwood]

Hm, the asset compiling prestart is taking too long, I am getting:

Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch

There are 2 solutions I can see:

1. Use postinstall instead of prestart. This should work on heroku, but may be a pain in local development, as it will execute after every npm install
2. Precompile assets locally in a deploy script, then push the resulting code to heroku. This is a bit tricky in a local dev environment, but is pretty straightforward when doing continuous deployment from CI.

Any feedback welcome.

[harlantwood]

I implemented option (1) above in this PR. This now deploys correctly. Open to finishing option (2) as well, though I think its probably best done from CI, as in the example links above, as it is a lot of messing around with git branches for a dev box...

[davidfurlong]

Works for me, @willzeng can you put it on the test heroku instance when you get back?

[harlantwood]

I'm feeling more enthusiastic about option (2) above. I'll make another PR for that and reference it here. Let's hold off on merging this PR for now, so we can choose between the two strategies.

[harlantwood]

Not fully debugged yet, but here is a sneak peak at option (2) in action:

• The diff so far: https://github.com/willzeng/cograph/compare/dev...harlantwood:deploy3
• Circle CI running this code, and deploying any changes to a certain branch name (production in this case) to my test cograph heroku instance: -- expand the bin/deploy section to see the compilation and deploy to heroku.

Once it is working reliably I'll create a PR. This system is the best of all worlds, IMO; I will expand on that in the PR.

(Of course, CI is the ideal place to run your tests as well, as they get fleshed out.)

Feedback welcome as always.

[willzeng]

Thanks @harlantwood, getting continuous integration working would be great. This second would definitely be the way to go. What still needs to be set up for it to run reliably (besides configuring the tests)?

[harlantwood]

You're welcome @willzeng -- glad we agree on the second option being preferable.

I tested deployment about 10x in a row with zero failures, so now consider it reasonably reliable.

I opened #642 for that strategy; closing this one.