Using sequelize-cli with Heroku

[gcatto]

I recently upgraded my sequelize from 2.0.0-dev11 to 2.0.0-dev12 and, as part of that, I added in sequelize-cli. Everything is working locally fine, but when I tried to replicate that on Heroku, I ran into issues running when trying to migrate:

Running `node_modules/.bin/sequelize db:migrate -env staging` attached to terminal... up, run.5140
Sequelize [CLI: v0.2.4, ORM: v2.0.0-dev12]
[03:39:53] CLI version 3.6.2
[03:39:53] Local version 3.6.2

I assume I am missing some new or modified configuration I need to do for Heroku, but am at loss for what it might be. Any suggestions?

[sdepold]

OK this is weird :D Will try to reproduce that !

[sdepold]

Can you show me the configuration ?

[sdepold]

seems to work normally for me :-/ can you rerun the command connecting to heroku via heroku run bash ?

[gcatto]

Thanks for the prompt response! Interestingly, running it via bash worked for me, although I get some " Possibly unhandled errors":

Possibly unhandled error: column "foo" of relation "bar" already exists
  at [object Object].Connection.parseE (/app/node_modules/pg/lib/connection.js:526:11)
  at [object Object].Connection.parseMessage (/app/node_modules/pg/lib/connection.js:356:17)
  at Socket.<anonymous> (/app/node_modules/pg/lib/connection.js:105:22)
  at Socket.emit (events.js:95:17)
  at Socket.<anonymous> (_stream_readable.js:764:14)
  at Socket.emit (events.js:92:17)
  at emitReadable_ (_stream_readable.js:426:10)
  at emitReadable (_stream_readable.js:422:5)
  at readableAddChunk (_stream_readable.js:165:9)
  at Socket.Readable.push (_stream_readable.js:127:10)
  at TCP.onread (net.js:528:21)

Not yet sure if those are my fault or not... not getting them locally (although I develop on Windows, but not sure why that would matter in this case).

In case its still relevant, this is my config:

  "staging": {
    "dialect": "postgres",
    "username": "<username>",
    "password": "<password>",
    "database": "<database>",
    "host": "<host>",
    "port": <port>,
    "coffee": true
  }, 

Finally, I had been using the following command to run the sequelize commands from the command line, which does still doesn't work:

 heroku run node_modules/.bin/sequelize -env staging db:migrate

[gcatto]

So in my infinite wisdom, I realized that the reason I was getting weird errors was I forgot to specify the environment when I was running from bash. When I properly include that, I get the same output as when I was running it without bash:

~ $ sequelize db:migrate -env staging
sequelize db:migrate -env staging
Sequelize [CLI: v0.2.4, ORM: v2.0.0-dev12]
[14:13:33] CLI version 3.6.2
[14:13:33] Local version 3.6.2

[gcatto]

Soooo in re-reviewing everything, I realized it's because I needed another dash before env, so that its --env instead of -env. Sorry for the waste of time!

[gcatto]

I think I closed this early. I realized that while it looks to be working, it's running the migrations for production instead of staging, which is what I specified using --env:

heroku run node_modules/.bin/sequelize --env staging db:migrate
Running `node_modules/.bin/sequelize --env staging db:migrate` attached to terminal... up, run.3479

Sequelize [CLI: v0.2.4, ORM: v2.0.0-dev12]

Loaded configuration file "config/config.json".
Using environment "production".
[15:03:54] Using sequelizefile ~/node_modules/sequelize-cli/sequelizefile.js
[15:03:54] Starting 'db:migrate'...
[15:03:54] Finished 'db:migrate' after 73 ms
Running migrations...

Edit: the same thing happens when using heroku run bash too.

[gcatto]

It seems like that perhaps getEnvironment() in generic-helper.js is "defaulting" to process.env.NODE_ENV and that's why its running it in the production environment, instead of the specified environment in args?

Edit: sure enough, once I did heroku config:set NODE_ENV=staging and re-ran things, everything worked fine.

[sdepold]

so tldr: --env is not enforcing the right environment?

[gcatto]

If process.env.NODE_ENV is specified, then you can't override it with --env; unsure if that's desired or not

[sdepold]

ah! i see. hmmm. wow that is hard ... actually I would prefer the --env over the NODE_ENV because it more temporary and therefore more important?. opinion?

[gcatto]

In short: I think that's the right call.

I am relatively new to node... if process.env.NODE_ENV is always set in node to some default, then it always means that --env has no effect.

My experience with other languages/environments is that anything provided as a command line argument overrides any other configuration.

[sdepold]

alright cool. do you have any interest in fixing the issue?

[sdepold]

cli/lib/helpers/generic-helper.js

Line 24 in e5471a1

return process.env.NODE_ENV || args.env || 'development'

[gcatto]

Sure! Am a bit new to Github, doesn't seem like I can propose edits to the file, nor create a branch to do it in... do I need to be given rights or some such?

[sdepold]

uhm... actually there should be an edit button at the top of the page

[gcatto]

So there is, but its disabled and has the tooltip, "You must be on a branch to make or propose changes to this file." The branches page doesn't seem to have anywhere to add a branch either. I also tried doing it locally and pushing the branch, but did not have permissions to do so.

[sdepold]

Oh interesting. Then: https://help.github.com/articles/fork-a-repo

tldr: Fork it, clone it, create a branch, fix the issue, do a git push origin <branch-name> -u, go to your github page of the repository, click on the button create pull request, press submit

[gcatto]

Thanks kindly! I think its all set and ready: #34