This project is deprecated and is no longer being maintained. For and updated version, see https://github.com/Xavdidtheshadow/heroku-config.
Please check out my current project Convox for all of your deployment needs!
Sync local environment to/from heroku
This project is deprecated and is no longer being maintained. For and updated version, see https://github.com/Xavdidtheshadow/heroku-config.
Please check out my current project Convox for all of your deployment needs!
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:
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.
$ 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.