search

laserlemon / figaro

Simple Rails app configuration
MIT License
3.77k stars 288 forks source link

A note about updating to 1.0.0 #148

Open l8nite opened 10 years ago

l8nite commented 10 years ago

Had an issue today where values in config/application.yml were being skipped by Figaro when restarting our unicorn servers. At some point in the recent past our application was updated to figaro 1.0.0.rc1 from 0.7.0.

This change introduced some logic that lets figaro set environment variables it "owns", but skips loading them otherwise: https://github.com/laserlemon/figaro/commit/ac00b48025d38819615c926ad394a23948d6f914

Since our application updates are done via USR2 signal to Unicorn, it seems that even though we've brought in the new figaro gem, the skip? logic is preventing it from replacing/updating those variables which had previously only existed without the FIGARO prefix.

The fix was either: 1) do a downtime deployment of the application (cold restart) 2) patch the lib/figaro/application.rb file to "return false" from the skip? method as a one-time fix so that it properly set the prefixed environment variable names, deploy the code, then undo the patch and deploy as normal

This issue is more FYI than something that actually needs to get fixed: perhaps something could be written in the README about it.

laserlemon commented 10 years ago

Would you be willing to write it up?

joshco commented 10 years ago

I have a similar issue, especially in development. I'll often have multiple rails projects on the same machine, but in different directories. Some of them will use the same env keys, but with different values. Rather than having to unpleasantly manage my actual environment variables, I depend on application.yml in an individual app directory to make every thing right. An example: each app has FACEBOOK_APP_ID, etc, but unique values

I didn't see a very elegant approach to make an override. I chose an env var FIGARO_OVERRIDE == "true". When set, the skip function will always return false.

I thought about an initializer or class variable, but wasn't sure when that would execute vs figaro (eg would that be too late in the app startup process?)

If there's another approach you would prefer, I'm happy to update my pull request.

joallard commented 9 years ago

+1 This is an enormous pain