e05536529e
to specify the (singular) key you will operate on, so address a specific node when it's a distributed redis client Change-Id: I9c4c0ab7114ea491439b42e4f4310f81470422a7 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/331131 Reviewed-by: Aaron Ogata <aogata@instructure.com> Build-Review: Aaron Ogata <aogata@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> QA-Review: Cody Cutrer <cody@instructure.com> Product-Review: Cody Cutrer <cody@instructure.com> |
||
|---|---|---|
| .. | ||
| activesupport-suspend_callbacks | ||
| acts_as_list | ||
| adheres_to_policy | ||
| attachment_fu | ||
| autoextend | ||
| bookmarked_collection | ||
| broadcast_policy | ||
| canvas_breach_mitigation | ||
| canvas_cache | ||
| canvas_cassandra | ||
| canvas_color | ||
| canvas_crummy | ||
| canvas_dynamodb | ||
| canvas_errors | ||
| canvas_ext | ||
| canvas_http | ||
| canvas_kaltura | ||
| canvas_mimetype_fu | ||
| canvas_panda_pub | ||
| canvas_partman | ||
| canvas_quiz_statistics | ||
| canvas_sanitize | ||
| canvas_security | ||
| canvas_slug | ||
| canvas_sort | ||
| canvas_stringex | ||
| canvas_text_helper | ||
| canvas_time | ||
| canvas_unzip | ||
| config_file | ||
| csv_diff | ||
| diigo | ||
| dr_diff | ||
| dynamic_settings | ||
| event_stream | ||
| google_drive | ||
| html_text_helper | ||
| i18n_extraction | ||
| i18n_tasks | ||
| incoming_mail_processor | ||
| json_token | ||
| legacy_multipart | ||
| live_events | ||
| lti-advantage | ||
| lti_outbound | ||
| paginated_collection | ||
| plugins | ||
| request_context | ||
| rubocop-canvas | ||
| stringify_ids | ||
| tatl_tael | ||
| turnitin_api | ||
| utf8_cleaner | ||
| workflow | ||
| README.md | ||
| test_all_gems.sh | ||
README.md
Gems
This folder is a place to extract modular functionality from canvas. Canvas's Gemfile arrangement is enabled to read gems from this path locally without installing from a remote source. This is valuable for a few reasons:
- it prevents circular dependencies (bundler won't allow it)
- modularized code cannot bind to specific domain concepts on canvas models
- gems can have their specs run independently, without needing to load all of canvas, saving iteration time
- it allows for eventual build optimization via only running specs for the transitive closure of parents depending on a gem where a change is.
There are some tradeoffs:
- spreads canvas over more subdirectories, giving some mental overhad to traversing the entire codebase.
- modular tests necessarily don't test integration with canvas concepts, so solid integration tests in the app are still a requirement.
- total SERIALIZED build time goes up because each gem loads it's specs in a new process rather than all running within an already booted canvas process.
[TODO] eventually write more on whether we feel like those tradeoffs are good ones, and what the best practices are to leverage this pattern for max-gain/min-pain.
Testing
To test all the gems:
cd gems
./test_all_gems.sh
To test an individual gem
Run ./test.sh inside the gem's folder. This is basically the same as:
cd gems/google_drive
bundle
rspec