Hi,

When I preform heroku config:push --app APP_NAME

I get the following:

Config in .env written to APP_NAME

However, when I am checking the web app .env file with heroku config --app APP_NAME it is not getting updated.

Could you provide me any advice?

Thanks

So I can source it

heroku plugins:install git://github.com/ddollar/heroku-config.git
Installing heroku-config... failed
! Could not install heroku-config. Please check the URL and try again.

any suggestions?

thanks

Heroku toolbelt already installed via Homebrew.

$  heroku plugins:install git//github.com/ddollar/heroku-config.git
Installing heroku-config... failed
 !    Could not install heroku-config. Please check the URL and try again.

Does this require the foreman gem? If so, it might be good to point that out. (I haven't installed Ruby or any gems yet.)

Given a .env file

MY_ENV_VAR=my\$isinthebank
MY_ENV_VAR2="my\$isinthebank"

It's expected that MY_ENV_VAR and MY_ENV_VAR2 are set to my$isinthebank after heroku config:push.
Instead, MY_ENV_VAR is set to my\$isinthebank and MY_ENV_VAR2 fails heroku config:push silently (due to a YAML parser exception).

I haven't provided a PR here because I'm not sure what should be done.
It seems there would be multiple characters that should be escaped to keep compatibility with shells (.env files should work as sources as well). That said, maybe heroku-config should unescape those caracters.
Any ideas?

What about removing all forward-slashes but the literal ones (i.e. \\).
There's still an issue with escapes within quotes. See:

$ echo "my\$isinthebank"
my$isthebank

$ echo "donot\escape"
donot\escape

$ echo donot\escape
donotescape

Within quotes, forward-slashes are always considered literal. Dollar-sign seems to be an exception. Do you guys know what are the others? (shell newbie here)

Finally, I'd like to note that single quoted values are okay with dollar-signs echo 'my$isinthebank' => my$isinthebank.

Googlers:

• a quick solution would be to use another password without dollar-signs or other characters that may require escaping even within double quotes.
• as of May, 22, heroku-config doesn't support single-quote wrapped values. But maybe soon it will.

Hey there,

Thanks for this helpful tool! Just ran into an issue where Foreman's behavior for parsing .env files has changed, but this plugin's behavior has not -- specifically support for quotes:

https://github.com/ddollar/foreman/blob/master/lib/foreman/engine.rb#L56-L70
vs.
https://github.com/ddollar/heroku-config/blob/master/lib/config/heroku/command/config.rb#L43-L52

Given that the Heroku toolbelt installs Foreman alongside the CLI, maybe it'd be best to require Foreman for reading the .env file instead of duplicating the code here? But not sure if that's possible or easy.

Thanks for the consideration!

EDIT: Writing needs updating too: https://github.com/ddollar/heroku-config/blob/master/lib/config/heroku/command/config.rb#L58-L64

Per these popular dotenv libraries, files should be written in the format

DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3

As it stands, pull writes them like

DB_HOST="localhost"
DB_USER="root"
DB_PASS="s1mpl3"

which causes severe headache for idiot developers like myself. The culprit is this line, which calls .inspect on the value. This adds extra quotes. eg:

2.2.3 :001 > value = "secret_pass"
2.2.3 :002 > puts "PASSWORD=#{value.inspect}"
PASSWORD="secret_pass" # bad, trips up libs
2.2.3 :003 > puts "PASSWORD=#{value}"
PASSWORD=secret_pass # good, desired behavior

I'm not sure if this totally breaks workflows, but it would be a welcome change. I'm happy to make the PR.

Pushing an .env of the format

export VAR_1="..."
export VAR_2="..."
export VAR_3="..."
...

using $> heroku config:push and then checking the resulting config shows zero change, without the command having said anything at all. No errors, no warnings, no notices.

With the new CLI version (heroku-toolbelt/2.30.5 (universal-darwin11.0) ruby/1.8.7), these deprecation warning are returned with this plugin:

! DEPRECATED: Heroku::Client#deprecate is deprecated, please use the heroku-api gem.
! DEPRECATED: More information available at https://github.com/heroku/heroku.rb
! DEPRECATED: Deprecated method called from /Users/brainard/.heroku/client/lib/heroku/client.rb:129.

Currently it is not supported to push a multiline variable from the .env file to heroku.

I set up my .env file like this:

FACEBOOK_KEY="XXXXX"
FACEBOOK_SECRET="XXXXXX"

EMBEDLY_USER_AGENT="XXXXX"
EMBEDLY_KEY="XXXXX"

foreman works great with this locally. So I decided to do a heroku config:push,

When I do that, heroku config creates variables on heroku with a value of "XXX" instead of XXX.

It would be nice if config:push only uses the value between "'s.

The README.md does not mention whether the following are accepted, or silently rejected:

export VAR="somevalue"

VAR="somevalue"

VAR=somevalue

Which of these will succeed, and which will get rejected?

The config:push option isn't giving desired behaviour, the values its pushing don't get set on Heroku.

I have an .env file for my staging environment at config/heroku.env.staging. The content is in shell format (because the Rails app is using the dotenv-deployment gem).

# config/heroku.env.staging
RACK_ENV=staging
RAILS_ENV=staging
...

I want to push these environment variables to my staging environment on Heroku. I tried both ways:

↪ heroku config:push --env=config/heroku.env.staging --app my-app-staging
Config in config/heroku.env.staging written to my-app-staging

↪ cat config/heroku.env.staging | heroku config:push --app my-app-staging
Config in STDIN written to my-app-staging

The output says it was successful but when I look at the environment variables for the app on Heroku, the values for RACK_ENV and RAILS_ENV haven't changed:

↪ heroku config --app my-app-staging
=== my-app-staging Config Vars
RACK_ENV:                       production
RAILS_ENV:                      production
...

It does work when I try to set a single environment variable with config:set (i.e. not using this plugin):

↪ heroku config:set RAILS_ENV=staging --app my-app-staging
Setting config vars and restarting my-app-staging... done, v53
RAILS_ENV: staging

I can confirm with config:get:

↪ heroku config:get RAILS_ENV --app my-app-staging
staging

Notice that with config:set it also restarts the app. Could that make a difference in the state being set/persisted?

Thanks so much for this great extension. We find it helps us quickly output our heroku config variables.

Returning to the command after a little time, we glanced at the README, skipped over the --env=production.env advice, and picked out the piping syntax for quickly creating a file out of our production .env file.

Pipe keys to STDOUT

$ heroku config:pull > config/production.env

While at one point this might have worked, the output of the command is now the human readable sentence "Config for pennsylvania-production written to .env" which I am sure no one truly wanted when piping, expecting instead something useful as production.env.

In my tragi-comic case, I saw that the file contained just one line, assumed it failed (without reading it and realizing that my .env file had been overwritten), and later ran tests that wiped our production database at DATABASE_URL.

All of that was my fault -- when the pipe did not produce what was expected, I should have read what was in it and confirmed that my .env was not overwritten. I should have also known that heroku DATABASE_URL settings override everything else you set for the your local environments, making a pull from a rails app especially dangerous.

That said, I think the piping lines on the read me should be removed or the output changed to something that can be piped normally. Let me know what you think! It is probably beyond the scope of the gem to warn other numbskulls like me about DATABASE_URL and other potentially catastrophic environmental variables being set in .env, but if you have heard of this before it might be worth considering.

Happy to submit a PR with verbiage once an approach is picked. Thanks again for the great plugin and all the work you put into it.