canvas-lms/gems/config_file
Cody Cutrer 0236850a35 bundle update minitest
Change-Id: I419dddede5ca12b1682f6c9cbb28686182204587
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/355104
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
Build-Review: Aaron Ogata <aogata@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
2024-08-23 14:11:12 +00:00
..
lib output config name when encountering a parser error 2023-07-06 16:33:07 +00:00
spec switch from byebug to debug 2023-09-20 23:48:39 +00:00
Gemfile bundle update --bundler 2024-04-01 14:22:00 +00:00
Gemfile.lock bundle update minitest 2024-08-23 14:11:12 +00:00
README.md extract ConfigFile to gem 2021-02-23 21:18:20 +00:00
config_file.gemspec switch from byebug to debug 2023-09-20 23:48:39 +00:00
test.sh extract ConfigFile to gem 2021-02-23 21:18:20 +00:00

README.md

Config File

In Canvas, This is how we load information from yaml files on disk at runtime.

Usage

You use ConfigFile by passing in the name of the file (no extension) to the "load" method.

ConfigFile.load('saml')

This will return you a hash that has the parsed yaml from that file. The module also knows about rails environments, and will try to pull the subset of the hash that is specific to the current rails env, but you can override it:

ConfigFile.load('database', 'test')

There are some nicities to this like the loaded hash always has indifferent access and if the file doesn't exist it doesn't error (you just get a null hash), and this helps with a number of common accidental errors.

The main value is that this information is cacheable (once the file is loaded, it's stored in memory according to it's filename). loading the same config many places will always result in the in-memory version being served.

There's also a more sophisticated caching mechanism if your config file gets loaded specifically to build some sort of in memory structure that you don't want to re-derive on each config load, like building a client object:

ConfigFile.cache_object('pv4') do |config|
  Pv4Client.new(config['uri'], config['access_token'])
end

In this kind of case, the parsed yaml is passed to the block as "config", and the value returned from the block is shoved into the object cache so that any other invocations of the "cache_object" method with the same key will just return the already built object.

Since all the config info we might load from disk is stored in one structure, it is simple to clear the cache to force a settings reload from disk.

ConfigFile.reset_cache

And the next time any bit of code asks for a given config file, it will be reloaded from disk.

Running Tests

This gem is tested with rspec. You can use test.sh to run it, or do it yourself with bundle exec rspec spec.