ERB Preprocessing

One of the nice things about Chamber (and in fact a lot of the configuration libraries do this) is that it runs each settings file through ERB before it tries to parse it as YAML.

This allows for much more dynamic content than you would be able to do with just YAML alone.

WARNING: Don't go too nuts with this stuff. Sometimes a little duplication is warranted for the sake of readability.

Runtime Values

If you're needing to do a little complex logic for one of your settings, ERB has you covered.

In this case we want to get both the time the app booted as well as the host name of the server.

system:
  boot_time: '<%= Time.utc.iso8601 %>'
  hostname:  '<%= Socket.gethostname %>'

Now, every time we boot the app, those settings will be dependent on the values at the time of boot.

WARNING: This only happens at boot when the YAML is parsed. For example in the YAML above, Time.utc.iso8601 does not get called each time Chamber.dig!('system', 'boot_time') is used.

Accessing Chamber Settings In Chamber Templates

Note: This bit is technically possible, but I'd suggest steering clear unless you have a distinct need for it.

Based on the order in which Chamber loads its settings files, the settings in prior files can be access in later files.

Example

# settings.yml

production:
  my_secret_key: 123456789

<%# settings/some_service-production.yml %>

my_service_url: http://my_username:<%= Chamber[:my_secret_key] %>@my-url.com

Because by default Chamber processes settings*.yml settings files before anything in the settings subdirectory, this works.

Dynamic Templating

Note: Another caveat here. If you want to do some dynamic templating using ERB, maybe make sure that raw YAML won't already do that sort of thing for you. A handy guide is here

Using ERB you can use any Ruby you'd like to automatically create dynamic templates. For example, you could use loops to loop over all the different environments:

<%# settings.yml.erb %>

<% %w{development test production}.each do |environment| %>
<%= environment %>:
  hostname_with_subdomain: <%= environment %>.example.com:3000

<% end %>

Would result in the following YAML being read:

development:
  hostname_with_subdomain: development.example.com:3000

test:
  hostname_with_subdomain: test.example.com:3000

production:
  hostname_with_subdomain: production.example.com:3000