Closed ericfranz closed 4 years ago
See https://apidock.com/rails/Rails/Application/config_for
The code:
paths["config"]
name
config_for
Rails.env
Two problems here:
The result is that if you have options that should appear in all envs you have to do something like this:
default: &default service_url: https://my_service.example.com development: <<: *default test: <<: *default production: service_url: <%= ENV['APP_SERVICE_URL'] %>
A custom config_for could do two things differently:
load default first, and then load env, so the yaml anchoring is redundant and can be removed. Thus the example above would be reduced to:
default
env
default: service_url: https://my_service.example.com production: service_url: <%= ENV['APP_SERVICE_URL'] %>
Search for configs in both /etc/ and root of the app (i.e. all of the paths in config). So if the root config appears, use that, otherwise, use /etc/
Such a method could be useful inside Configuration objects that individual OOD apps use.
Not doing.
See https://apidock.com/rails/Rails/Application/config_for
The code:
paths["config"]
that exists, and looks for the config specified by thename
argument toconfig_for
Rails.env
Two problems here:
The result is that if you have options that should appear in all envs you have to do something like this:
paths["config"]
, only /etc will ever be used, or only the root of the appA custom
config_for
could do two things differently:load
default
first, and then loadenv
, so the yaml anchoring is redundant and can be removed. Thus the example above would be reduced to:Search for configs in both /etc/ and root of the app (i.e. all of the paths in config). So if the root config appears, use that, otherwise, use /etc/
Such a method could be useful inside Configuration objects that individual OOD apps use.