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.

Reply via email to