I like the ideas in that PR, although I’m not 100% qualified to comment on them (we don’t use env vars).
It does raise the problem that secrets.yml is lazily evaluated, so I don’t know if my suggested check would/could run at boot-time :/ Chris On Fri, Mar 17, 2017 at 3:49 PM, Mohamed Wael Khobalatte < [email protected]> wrote: > Yes I think that would be a great addition. You will like reading this > discussion: https://github.com/rails/rails/pull/17175. Extending one of > the proposals there to require RAILS_ENV by default will solve your problem > I think. > > On Fri, Mar 17, 2017 at 11:39 AM, Chris S <[email protected]> wrote: > >> Good points. >> >> I could have been more explicit about my exact problem >> >> The glitch was that I’d indented `production`, so that the YAML parser >> was considering it a sub-key of `staging`. Obviously, accidentally deleting >> a character (`producion`, etc) would have similar effects. >> >> I agree it’s probably scope-creep to deal with malformed keys anywhere in >> the file, but it doesn’t seem outrageous to check if there’s a top level >> key which matches the current RAILS_ENV, and bail if not? >> >> Chris. >> >> >> On Fri, Mar 17, 2017 at 2:52 PM, Mohamed Wael Khobalatte < >> [email protected]> wrote: >> >>> Was the glitch in the YAML structure itself (which normally would throw >>> a parse exception and the app won't start), or was it a glitch in a value >>> (value is "\sabc" vs "abc")? The latter is almost impossible to solve, >>> considering that it hosts a wide variety of values, from API keys to your >>> own secrets. >>> >>> The way I deal with it is to try and figure out which values are just >>> too important for the app, say a cache host credentials, then attempt a >>> start of that service in an initializer, aborting the start the entire >>> application of no values are found in the secrets file. >>> >>> On Fri, Mar 17, 2017 at 9:28 AM, Chris S <[email protected]> wrote: >>> >>>> I’ve just suffered a long 20 minutes trying to debug why an app was >>>> broken: Missing its Rails.application.secrets, even though secrets.yml was >>>> in place and "looked" OK. >>>> >>>> The problem was a tiny whitespace glitch in my YAML, which meant the >>>> app was failing to load the secrets for its current environment. >>>> >>>> Should this be considered a bug? Does it make sense for the app to >>>> continue booting if it can’t find its secrets? >>>> >>>> I’d happily file a pull request for this if s., I’ve looked at the >>>> relevant code and it doesn’t seem to be a difficult change to make, but I >>>> wouldn’t want to commit the effort if I’m wrong about this and there are >>>> circumstances where it makes sense to plough on even if secrets can’t be >>>> loaded. >>>> >>>> Let me know, >>>> Chris. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ruby on Rails: Core" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/rubyonrails-core. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Wael Khobalatte >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Wael Khobalatte > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
