c7bf5fba48
Change-Id: I0df8f625c119b2622e358a5d663c158e2d7d7cb8 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/292904 Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> Reviewed-by: Alex Slaughter <aslaughter@instructure.com> QA-Review: Jacob Burroughs <jburroughs@instructure.com> Product-Review: Jacob Burroughs <jburroughs@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_i18nliner | ||
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 | ||
linked_in | ||
live_events | ||
lti-advantage | ||
lti_outbound | ||
multipart | ||
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.
- it gives ENGINES extracted from canvas (see the "engines" directory) a place to reference code shared with canvas without it being packaged into the canvas monolith directly.
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