I want to completely replace a Heroku config with a local .env file. The command below seems to only update values that are in both files, not erase server config settings. Any ideas on how to simply do this?
heroku config:push --overwrite
Assuming you're using OS-X, this can be accomplished with these two steps:
Unset config vars
$ heroku config:unset $(heroku config | perl -nle'print $& if m{(^.*)(?=:)}')
Push local .env
$ heroku config:push
Hope this helps :)
Ps: Keep in mind Heroku makes it simple to roll back changes made to config vars.
Related
I've tried many different solutions on the web for this problem, but all have been unsuccessful.
Here's the problem: My app needs to know whether it is being run on Heroku (production mode) or locally (development mode). For this purpose, we want to use environment variables. I've understood that environment variables on Heroku can be set in a .env file. So my attempt was to run heroku run bash -a <app-name> and then to install vim by doing this:
mkdir ~/vim
cd ~/vim
# Staically linked vim version compiled from https://github.com/ericpruitt/static-vim
# Compiled on Jul 20 2017
curl 'https://s3.amazonaws.com/bengoa/vim-static.tar.gz' | tar -xz
export VIMRUNTIME="$HOME/vim/runtime"
export PATH="$HOME/vim:$PATH"
cd -
Apart from crashing repeatedly, vim didn't work anymore when I logged in and out of the shell:
~ $ vim // in the heroku shell
vim: error while loading shared libraries: libXt.so.6: cannot open shared object file: No such file or directory
I also tried heroku plugins:install heroku-vim but running heroku vim after that only resulted in a long delay followed by the normal heroku shell opening, no vim.
I don't really care if I get vim to work. I just want to be able to write in a file named .env on Heroku so I can set environment variables in it.
How can I achieve this?
There is no need for an .env file on Heroku. In fact, such a file won't work very well since
Heroku gets all of its files from your Git repository,
has an ephemeral filesystem, meaning that changes to files like .env will be quickly lost, and
the .env file won't be available on other dynos if you scale your app
As such, creating an .env file on Heroku isn't a good approach.
Instead, you can use its built-in support for environment variables, using heroku config:set <var> <value> or its web UI. Either way, you'll get a regular environment variable.
It is fairly simple.
Just as you added them in your .env file, do the same with heroku's command line and you will see heroku restart and you are all set to fly again.
Just use the command :
(heroku config:set VARIABLE=this_is_the_value)
Remember to use the underscores in the value as spaces are not allowed not inverted quotes (" ")to turn it into a single string is permissible.
When I run heroku local
my console shows me:
[WARN] No ENV file found
How can I fix this?
Add an .env file. This files contains the local VARS that are different in your local setting from the heroku environment. However, if everything runs fine, you can just ignore the warning, or do touch .env.
You can also differentiate by creating a Procfile.local file and run heroku local -f Procfile.local, to force using a local start script.
I just read: https://devcenter.heroku.com/articles/heroku-local. That explains it all.
For a working example: http://github.com/halcwb/GenUnitApp.git. When you have the heroku toolbelt installed you can heroku local -f Procfile.bash on mac or linux, or heroku -f Procfile.local for windows, and go to http://localhost:3000, to check the result.
Our team is using foreman for development and .env files to preassign development ports to each piece of a service oriented application. It dramatically simplifies things for this file to just live with the repository as we are not doing any specific per-machine local configurations even though multiple docs seem to think this is a bad idea.
Does anybody know if Heroku will ignore these .env files automatically? What if they were added to .slugignore?
I setup a test app to try this out including a PORT=5005 in the .env file and then committing/deploying to Heroku. Heroku didn't seem to notice it was even there and no new config vars appeared when I checked heroku config.
You answered your own question, but just for confirmation: .env is entirely a Foreman construct, while Foreman and Heroku will make use of Procfile.
We actually wanted to be able to ensure consistent environments between local and Heroku deployments, so I wrote a python script to export .env up to Heroku.
In case others want to export .env to Heroku:
https://github.com/FinalsClub/karmaworld/blob/68f0f0340d7b6420e263cab648ff7de1ea851a0e/export_env_to_heroku.py
Doesn't seem to be a way to do it from the command line, and when I do this from the site, I run into this issue when I try to git push heroku master:
! No such app as [previous app name].
Is this as simple as changing how I point to the app in git?
Did you try heroku apps:rename NEWNAME?
Why use all caps?
heroku apps:rename my_new_app_name
Here is a great place to find out more:
How to rename your Heroku application
In case anyone is curious this method does not require any further configuration, your modifications should be immediate. At the time of this writing I was able to change the name of my app in seconds, and then do so again if I wished. Hope this helps.
heroku apps:rename new_name --app old-app-name
^ worked for me
If you are changing the name of the app on the webpage
you should Updating Git remotes
git remote rm heroku
heroku git:remote -a newname
https://devcenter.heroku.com/articles/renaming-apps
Use this:
heroku apps:rename --app old_name new_name
Try this command:
heroku rename new_app_name
heroku rename new-name-app
always works for me but for additional information on rules, follow this page.
to rename app use:
heroku apps:rename --app <old_name> <new_name>
then, remove remote heroku:
git remote rm heroku
and add new one:
heroku git:remote -a <new_name>
and push changes:
git push heroku <branch_name>:main
If you want to rename your heroku app use: heroku apps:rename new_name
Please replace "new_name" with the name you want to give your app. make sure you do not include any "https://" because this will give you an issue. simply replace new_name with your app name
e.g heroku apps:rename grapefruitblog
After doing this, heroku requires that you update git remotes for all other local checkouts of the app. you can do this by running this command: heroku git:remote -a new_name
Again, replace new_name with the name you previously put in
e.g heroku git:remote -a grapefruitblog
I'm using Heroku to host a Rails app, which means using Git to deploy to Heroku. Because of the "pure Git workflow" on Heroku, anything that needs to go upstream to the server has to be configured identically on my local box.
However I need to have certain configuration files be different depending on whether I'm in the local setup or deployed on Heroku. Again, because of the deployment method Heroku uses I can't use .gitignore and a template (as I have seen suggested many times, and have used in other projects).
What I need is for git to somehow track changes on a file, but selectively tell git not to override certain files when pulling from a particular repo -- basically to make certain changes one-way only.
Can this be done? I'd appreciate any suggestions!
You can have config vars persistently stored ON each heroku app's local setup so they do not have to be in your code at all! so the same code can run on multiple heroku sites but with different configuration. It very simple, easy, elegant...
It's the approach we used. (We used it for the SAME thing... we have multiple clones of the SAME app at Heroku, but we want only ONE source at github, in our dev local directory we do the PUSH to ORIGIN (github), then when we have it the way we like it, we CD to the prod local directory, which goes to the SAME github repository, and we ONLY PULL from GITHUB into this directory, never push (eg, all pushes to github come from our dev directory, the prod directory is just a staging area for the other heroku app.)
By having the different configs ON the different HEROKU sites (as explained below), the EXACT SAME CODE works on BOTH heroku sites.
So our workflow is: (the key is that BOTH directories point to SAME github repo)
cd myDEVdir
*....develop away....*
git add .
git commit -am "another day, another push"
git push origin *(to our SINGLE github repo)*
git push heroku *(test it out on heroku #1)*
cd ../myPRODdir
git pull *(grabs SAME code as used on other site *)
git push heroku *(now the SAME code runs on Heroku #2)*
that's it!
Now here's how you keep your site-specific config vars ON the heroku site:
http://docs.heroku.com/config-vars
on your local command line, for EACH of your two local directories, do:
$ heroku config:add FIRST_CONFIGVAR=fooheroku1
Adding config vars:
FIRST_CONFIGVAR => fooheroku1
$ heroku config:add SECOND_CONFIGVAR=barheroku1
Adding config vars:
SECOND_CONFIGVAR => barheroku1
to see the ones you have defined:
$ heroku config
FIRST_CONFIGVAR => fooheroku1
SECOND_CONFIGVAR => barheroku1
then cd to your other directory myPRODdir and do the SAME thing, only set the same remote heroku vars to fooheroku2 and barheroku2.
then in your rails app you simple refer to them like so:
a = ENV['FIRST_CONFIGVAR']
One app will read 'fooheroku1' the other app will read 'fooheroku2'
And finally, on your LOCAL directory myDEVdir, where you run in DEV mode, put the same config commands in your config/environment/development.rb file your 'dev' version of the config vars will be set to whatever they should be:
ENV['FIRST_CONFIGVAR'] = "foodev"
ENV['SECOND_CONFIGVAR'] = "bardev"
Easy, elegant. Thanks, Heroku!
Here are a few solutions:
1) If you want to ignore files only on heroku, use slugignore
2) If your changes are minor, stay DRY and use universal config files, inserting switches for server-specific behavior
if Rails.env == "production"
#production server code
elsif Rails.env == "development"
#development server code
else
#test server code
end
3) If your changes are major, write one config file and add a "smudge file" to config/initializers for each additional server. Basically, you would have separate files using the technique in (2).
4) If your changes are SWEEPING (unlikely), then maintain separate branches for each server.
5) This script can do exactly what you requested, but may be overkill.
I hope that helped.