I have the following constant in production.rb:
GSA_EPLS_DATASOURCE = FILESTORE + “/” + “datafiles/gsa_epls.xml”
The constant FILESTORE is located in environment.rb:
FILESTORE = “…/creditcompare_filestore/” + Rails.env
When I try to migrate my db on heroku I get this error which points to the line above in production.rb
uninitialized constant FILESTORE
So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?
I have the following constant in production.rb:
GSA_EPLS_DATASOURCE = FILESTORE + "/" + "datafiles/gsa_epls.xml"
The constant FILESTORE is located in environment.rb:
FILESTORE = "../creditcompare_filestore/" + Rails.env
When I try to migrate my db on heroku I get this error which points to the line above in production.rb
uninitialized constant FILESTORE
So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments... I dont have to but would like to. Is there a way to do what I am trying to do?
I see you already solved this, but you might look into something like SettingsLogic....
When I try to migrate my db on heroku I get this error which points to the line above in production.rb
uninitialized constant FILESTORE
So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?
I see you already solved this, but you might look into something like SettingsLogic…
Hey Philip, that looks really cool - thanks for sharing. Not sure if you know, but my challenge is I push to heroku for staging (product owner review), but my production environment is elsewhere on our own Ubuntu server. Is there a way to create two production environments – say :production_heroku and :production_live? What I am doing now is having an extra production.rb off in a sub folder and when I push to the real production environment I tell capistrano to replace the existing production file which corresponds to heroku…
I realized I read to quickly… heroku has it’s own deployment setup. If you can change the environment you to deploy to on heroku then you could still do what I’ve said above. Otherwise, you could cheat and create :production (for heroku) and :really_really_production (for ubuntu) and then use what I’ve said above. Not quite as nice, but it would work.
When I try to migrate my db on heroku I get this error which points to the line above in production.rb
uninitialized constant FILESTORE
So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?
I see you already solved this, but you might look into something like SettingsLogic…
Hey Philip, that looks really cool - thanks for sharing. Not sure if you know, but my challenge is I push to heroku for staging (product owner review), but my production environment is elsewhere on our own Ubuntu server. Is there a way to create two production environments – say :production_heroku and :production_live? What I am doing now is having an extra production.rb off in a sub folder and when I push to the real production environment I tell capistrano to replace the existing production file which corresponds to heroku…
Create a “staging” environment file, entry in database.yml, and anywhere else you have development/production stuff…
Then you can do
cap staging deploy # to heroku
cap production deploy # to ubuntu
Thanks. I had not really considered using cap to deploy to heroku but makes sense and will actually save me some manual work once I build out the cap file.
Thanks. I had not really considered using cap to deploy to heroku but
makes
sense and will actually save me some manual work once I build out the
cap
file.
Why would you use Cap to deploy to Heroku? *How* would you even do
that? By setting some environment variables and calling git push?
If that's all, then it's probably not necessary. Heroku has its own
configuration interface for setting environment variables (and you could
set RAILS_ENV if you wanted it to be "production_heroku" instead of
"production").
Thanks. I had not really considered using cap to deploy to heroku but
makes
sense and will actually save me some manual work once I build out the
cap
file.
Why would you use Cap to deploy to Heroku? How would you even do
that? By setting some environment variables and calling git push?
If that’s all, then it’s probably not necessary. Heroku has its own
configuration interface for setting environment variables (and you could
set RAILS_ENV if you wanted it to be “production_heroku” instead of
“production”).
For one, my storage location is different - I use S3. This is probably the only major setting difference. Right now I manually change the variable, but that opens me up to not turning it off when I push to production. So you are saying I could create a new rails environment that is Heroku? Do you know offhand how I would tell heroku to use “production_heroku” rather than production? I thought it just automatically used “production” in all cases.
>>
If that's all, then it's probably not necessary. Heroku has its own
configuration interface for setting environment variables (and you could
set RAILS_ENV if you wanted it to be "production_heroku" instead of
"production").
For one, my storage location is different - I use S3. This is probably
the
only major setting difference. Right now I manually change the variable,
but
that opens me up to not turning it off when I push to production.
No, in fact it doesn't. Heroku has a completely independent interface
for setting config variables, so there's nothing to forget to turn off.
So you
are
saying I could create a new rails environment that is Heroku? Do you
know
offhand how I would tell heroku to use "production_heroku" rather than
production? I thought it just automatically used "production" in all
cases.
Rails always, always, always uses whatever environment RAILS_ENV tells
it to use (or "development" if RAILS_ENV isn't set). So just set
RAILS_ENV to something else.