attempting Heroku deployment

[MatthewVita]

@whit537 starting out here.

Going to set up a fresh heroku box and try these rake tasks. I'm not sure if doing the steps through rake tasks is the most elegant approach, tbh.

[MatthewVita]

$ heroku login $ heroku create $ heroku config:set RAILS_SERVE_STATIC_FILES=enabled $ heroku config:set RAILS_ENV=production $ heroku config:set RAILS_ENV=production $ heroku config:set APP_TOKEN=foo123abc $ heroku config:set APP_SECRET=bar789xyz $ heroku config:set APP_DATABASE_USER=somebody $ heroku config:set APP_DATABASE_PASS=somepass $ git push heroku heroku-matthew:master $ heroku run rake db:migrate $ heroku run rake db:seed $ heroku run rake npm $ heroku run rake gulp

...note that everything is good until the rake npm and gulp commands :( I don't know where the app directory is on heroku

[MatthewVita]

wait...

matthew@matthew-VirtualBox ~/code/cityasacampus $ heroku run bash
Running bash on arcane-island-8296... up, run.2489
~ $ ls
app   config     dev           GETTING_STARTED.md  Rakefile   vendor
app.json  config.ru  examples      lib         README.md
bin   datamodel.pdf  Gemfile       log         test
client    db         Gemfile.lock  public          tmp
~ $ pwd
/app
~ $ 

w00t! need to amend this branch

[MatthewVita]

btw, we're https://arcane-island-8296.herokuapp.com/dashboard/users/sign_in

[MatthewVita]

https://arcane-island-8296.herokuapp.com/ has no static assets to serve up atm, of course

[chadwhitacre]

@MatthewVita The db:migrate and db:seed tasks are one-time, right? How about npm and gulp? Do those need to be run once, or every time we deploy?

[chadwhitacre]

Heroku is designed for dynamic resources, not static ones. We should consider using a CDN for our static assets. Here's Heroku's docs on integrating with Amazon CloudFront. Over on Gratipay, we're using MaxCDN successfully for static assets.

[chadwhitacre]

What's our current static setup? How do npm/gulp interact with the Rails asset pipeline, if at all?

[MatthewVita]

@whit537 I should be clear: gulp just "compiles" our frontend to the Rails "public" directory

[MatthewVita]

db:migrate, npm, and gulp should be run every push, yes

[chadwhitacre]

Okay, and the npm install is so we can use gulp, right?

[MatthewVita]

yes, and so we can have frontend dependencies resolved (such as angular, jquery, etc)

[chadwhitacre]

Resolved when/where? Per-request on the server side or something?

[MatthewVita]

npm downloads the dependencies and gulp shoves them into the vendors.min.js and vendors.min.css files

[chadwhitacre]

Looks like you're on the right track with heroku run rake db:migrate:

https://devcenter.heroku.com/articles/getting-started-with-rails4#migrate-your-database

[chadwhitacre]

npm downloads the dependencies and gulp shoves them into the vendors.min.js and vendors.min.css files

Okay, so still only happening once per deploy.

[chadwhitacre]

Regardless of the webserver you choose, production apps should always specify the webserver explicitly in the Procfile.

https://devcenter.heroku.com/articles/getting-started-with-rails4#webserver

[MatthewVita]

cool. Do you mind looking into that? I'm currently fighting with getting rake task to run correctly (almost there...)

[MatthewVita]

btw, WebBrick is currently what's being used, which is not good

[chadwhitacre]

Some pointers for static files:

• https://devcenter.heroku.com/articles/rails-asset-pipeline
• https://devcenter.heroku.com/articles/rails-4-asset-pipeline
• https://github.com/heroku/rails_12factor#rails-4-serve-static-assets
• RAILS_SERVE_STATIC_FILES

[MatthewVita]

damnit. Heroku has node installed by default but not npm...

[chadwhitacre]

Do you mind looking into that?

Sure thing! :-)

[MatthewVita]

heroku buildpacks:set https://github.com/heroku/heroku-buildpack-nodejs#v83

hmmmm

[MatthewVita]

remote:  !     Push rejected, failed to detect set buildpack https://github.com/heroku/heroku-buildpack-nodejs#v83
remote: More info: https://devcenter.heroku.com/articles/buildpacks#detection-failure

https://github.com/heroku/heroku-buildpack-nodejs#v83
Unsetting https://github.com/heroku/heroku-buildpack-nodejs#v83 and restarting arcane-island-8296... done

nope :(

[chadwhitacre]

I've achieved parity with https://github.com/saxifrage/cityasacampus/pull/358#issuecomment-160186785:

http://still-tor-9977.herokuapp.com/dashboard/users/sign_in

[chadwhitacre]

/me reads https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server

[MatthewVita]

/me trying to figure out how to install npm with buildpacks and failing miserably lol

[chadwhitacre]

@MatthewVita Not sure how you're approaching it, but you should only have one buildpack per application. Either we use Heroku's official Rails buildpack, or their official Node.js one, or we roll our own that combines the two. Seems like we should be able to find a way to install npm without rolling our own buildpack.

[MatthewVita]

@whit537 was under the impression that you could have multiple buildpacks. Thanks for clarifying.

Seems like we should be able to find a way to install npm without rolling our own buildpack.

This is what's killing me. The box comes with Node 0.10 but doesn't come with NPM. I'm learning the hard way that we can't just heroku run bash and try to install things willy-nilly.

Either my Google-fu is bad today or there really isn't anyone else with this problem on the web >.<

[MatthewVita]

oh wait, https://github.com/ddollar/heroku-buildpack-multi

[chadwhitacre]

oh wait, https://github.com/ddollar/heroku-buildpack-multi

Cool. Maybe that'll do the trick.

The box comes with Node 0.10

That's pretty old, isn't it?

I'm learning the hard way that we can't just heroku run bash and try to install things willy-nilly.

Because dynos get thrown away, you mean? We'd have to run the same commands against the new dyno each time we deploy, right?

[chadwhitacre]

We'd have to run the same commands against the new dyno each time we deploy, right?

We do roughly that over in Gratipay-land:

https://github.com/gratipay/gratipay.com/blob/1928/release.sh#L94-L100

[MatthewVita]

Cool. Maybe that'll do the trick.

I think so. Trying out now but Heroku CLI is being weird asking for the app name with each command. Need to fix this.

That's pretty old, isn't it?

Yes. 😩

[chadwhitacre]

Trying out now but Heroku CLI is being weird asking for the app name with each command.

Make sure you're in the root directory of the project. I believe the CLI looks at .git/config to determine which app to use.

[MatthewVita]

Thanks. That did it

[chadwhitacre]

Yes. 😩

It's presumably the version of node that's included in a stock 14.04 install.

$ heroku run "lsb_release -a"
Running lsb_release -a on still-tor-9977... up, run.6114
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty
$

[chadwhitacre]

Alright, we're running puma. Looks like we're serving static assets, too:

http://still-tor-9977.herokuapp.com/assets/manifest-22d7acf2dd85b12e6ace0f8d6b3532a7.json

Once we are able to compile assets per-deploy we should be minimally hostable on Heroku! :-)

[chadwhitacre]

Alright, outta time for today over here @MatthewVita. Good luck with node/npm! :-)

[MatthewVita]

Okay. I'm going to pick up my car (all fixed up!).

Going to give myself a break before I jump back in later today or tomorrow. I'll update you on my node/npm progress. I'm thinking that the Node buildpack will magically solve all of my problems but I haven't actually looked to see which version it contains xD

[MatthewVita]

take care!

[MatthewVita]

GOOD NEWS: the node buildpack has the latest and greatest stable node/npm

BAD NEWS: after running these steps:

$ heroku login
$ heroku create
$ heroku buildpacks:set heroku/ruby
$ heroku config:set RAILS_SERVE_STATIC_FILES=enabled
$ heroku config:set RAILS_ENV=production
$ heroku config:set RAILS_ENV=production
$ heroku config:set APP_TOKEN=foo123abc
$ heroku config:set APP_SECRET=bar789xyz
$ heroku config:set APP_DATABASE_USER=somebody
$ heroku config:set APP_DATABASE_PASS=somepass
$ git checkout heroku-matthew
$ heroku buildpacks:add --index 1 heroku/nodejs
$ git push heroku heroku-matthew:master

I get this:

matthew@matthew-VirtualBox ~/code/cityasacampus $ git push heroku heroku-matthew:master
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 245 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote: 
remote: -----> Using set buildpack heroku/nodejs
remote: 
remote:  !     Push rejected, failed to detect set buildpack heroku/nodejs
remote: More info: https://devcenter.heroku.com/articles/buildpacks#detection-failure
remote: 
remote: Verifying deploy...
remote: 
remote: !   Push rejected to stormy-thicket-8019.
remote: 
To https://git.heroku.com/stormy-thicket-8019.git
 ! [remote rejected] heroku-matthew -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/stormy-thicket-8019.git'

[MatthewVita]

fixed node/npm buildpack problem via https://github.com/saxifrage/cityasacampus/commit/ba320df98bdd0ff21c512353ffa54d92888a4044

[MatthewVita]

matthew@matthew-VirtualBox ~/code/cityasacampus $ heroku run rake npm
Running rake npm on still-mountain-2357... up, run.6128
npm WARN package.json cityasacampus.org@0.0.1 No README data
angular-route@1.3.14 node_modules/angular-route

angular@1.3.14 node_modules/angular

jquery@2.1.3 node_modules/jquery

moment@2.10.2 node_modules/moment

angular-filter@0.5.4 node_modules/angular-filter

masonry-layout@3.3.2 node_modules/masonry-layout
├── get-size@1.2.2 (desandro-get-style-property@1.0.4)
├── fizzy-ui-utils@1.0.1 (desandro-matches-selector@1.0.3, doc-ready@1.0.3)
└── outlayer@1.4.2 (desandro-get-style-property@1.0.4, eventie@1.0.6, desandro-matches-selector@1.0.3, doc-ready@1.0.3, wolfy87-eventemitter@4.3.0)

Success!!! Kind of!!!

matthew@matthew-VirtualBox ~/code/cityasacampus $ heroku run rake gulp
Running rake gulp on still-mountain-2357... up, run.3058
npm WARN deprecated lodash@1.0.2: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^3.0.0.
/app/.heroku/node/bin/gulp -> /app/.heroku/node/lib/node_modules/gulp/bin/gulp.js
gulp@3.9.0 /app/.heroku/node/lib/node_modules/gulp
├── interpret@0.6.6
├── pretty-hrtime@1.0.1
├── deprecated@0.0.1
├── archy@1.0.0
├── minimist@1.2.0
├── tildify@1.1.2 (os-homedir@1.0.1)
├── v8flags@2.0.10 (user-home@1.1.1)
├── semver@4.3.6
├── chalk@1.1.1 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2.1.0, strip-ansi@3.0.0, has-ansi@2.0.0)
├── orchestrator@0.3.7 (stream-consume@0.1.0, sequencify@0.0.7, end-of-stream@0.1.5)
├── liftoff@2.2.0 (extend@2.0.1, rechoir@0.6.2, flagged-respawn@0.3.1, findup-sync@0.3.0, resolve@1.1.6)
├── vinyl-fs@0.3.14 (graceful-fs@3.0.8, strip-bom@1.0.0, vinyl@0.4.6, defaults@1.0.3, through2@0.6.5, mkdirp@0.5.1, glob-stream@3.1.18, glob-watcher@0.0.6)
└── gulp-util@3.0.7 (array-differ@1.0.0, array-uniq@1.0.2, lodash._reinterpolate@3.0.0, object-assign@3.0.0, lodash._reevaluate@3.0.0, lodash._reescape@3.0.0, beeper@1.1.0, fancy-log@1.1.0, replace-ext@0.0.1, has-gulplog@0.1.0, vinyl@0.5.3, gulplog@1.0.0, lodash.template@3.6.2, through2@2.0.0, multipipe@0.1.2, dateformat@1.0.12)
[21:36:07] Local gulp not found in ~/client
[21:36:07] Try running: npm install gulp

Failure!! :/ :/ :/

[MatthewVita]

Okay, we need NODE_ENV to not be production so the gulp dev dependencies can be brought in. Need to update the branch real quick and am going to give this another try.

[MatthewVita]

okay, so it turns out that my approach is entirely wrong and I need to handle this another way because:

even though the node_modules are getting saved locally, they are wiped away just like that (similar to the FOOBAR.txt example)

[MatthewVita]

apparently people are saying these tasks needs to go into the root package.json postinstall area

[MatthewVita]

@whit537 just an update for you. So if you read my previous comments I was able to get Ruby/Node/Npm to sing on the Heroku instance. However, I found that Rake approach is wrong (it will bring down NPM and try to compile the files with Gulp but nothing gets saved basically -- for example if one runs heroku run bash and touch foobar.txt it will appear but If you relogin to the instance, it will be gone).

I read about some install alternative options and found that Nodejs projects were using package.json scripts area to trigger post install commands so I inserted in my commands as followed:

...but it doesn't work. It errors with ./postinstall.sh: line 3: cd: /app/client: No such file or directory... not sure why it fails but it could be because the primary buildpack is ruby. /app/client doesn't technically exist on disk at this point in time. Not really many options at this point, AFAIK.

Also found this relevant SO comment:

I was never super happy with how many people seemed ok with checking in your generated code into git or the NPM postinstall hook. :(

^ I feel like at this point we may just want to resort to making a release branch that doesn't .gitignore public and write up some steps on making sure that we run npm install && gulp production and then push via git push heroku release:master. Not super happy about this approach but we could hook up CI that does this when something to pushed to release?

Else, maybe we can explore other Heroku-like PaaSs that are more friendly to our Rails/Angular use case? Here are some contenders:

• https://www.engineyard.com/
• http://www.cloud66.com/
• https://www.openshift.com/
• https://www.dotcloud.com/
• https://www.clever-cloud.com/en/

UPDATE: just tried engineyard and don't think we'll go too far there ::table_flip::

[chadwhitacre]

I gather that what we're doing is replacing the Rails asset pipeline with our own Gulp-based solution. Yes?

Heroku makes deploying SUPER easy, but there are a couple of things you'll need to do to get this running.

Since we're using Ruby (to run Rails) AND Node (to compile our assets with Gulp) in our setup, we need both running on our server.

https://github.com/vigetlabs/gulp-rails-pipeline#heroku

[chadwhitacre]

apparently people are saying these tasks needs to go into the root package.json postinstall area

Looks like that is what https://github.com/vigetlabs/gulp-rails-pipeline is doing:

https://github.com/vigetlabs/gulp-rails-pipeline#packagejson

[chadwhitacre]

We're on the right track.

For example, run a JavaScript buildpack for assets and a Ruby buildpack for your application.

https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app

[chadwhitacre]

In fact, it sounds like we don't even need to use buildpack-multi anymore.