flag=none
Looks like there were a couple of typos in this file.
Test plan:
* looks good now?
Change-Id: I0c3c513b774a5b999f1b4086d5bf0b6383e894bb
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/235999
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Tested-by: Simon Williams <simon@instructure.com>
Tested-by: Charley Kline <ckline@instructure.com>
Fixes: CCI-347
This will allow connecting to the test environment again.
Copy over the updated config/docker-compose.override.yml (or delete the
relevant line from your existing docker-compose.override.yml). Also copy
over the restored and modified config/database.yml.example.
$ cp -iv config/docker-compose.override.yml.example \
docker-compose.override.yml
$ cp -iv docker-compose/,}config/database.yml
If you have existing databases that don't match the naming scheme of
"canvas_<ENV>" then you'll need to do a custom configuration for your
database names in config/database.yml or rename your databases in
postgres.
Test Plan
- update your override config and database.yml:
$ cp -iv config/docker-compose.override.yml.example \
docker-compose.override.yml
$ cp -iv {docker-compose/,}config/database.yml
- make sure your postgres image is up to date from earlier patchset
(this will remove all your data):
$ docker-compose down --volumes
$ docker-compose build --no-cache postgres
- boot the app, bundle, and wait for postgres to be available (for
internal start up scripts to run):
$ docker-compose run --rm web bundle \
&& docker-compose run --rm web build/new-jenkins/wait-for-it \
postgres:5432 -t 30
- test that connctions to both development and test databases work:
- developement:
$ docker-compose run --rm web bin/rails runner \
'puts ActiveRecord::Base.connection.current_database'
=> 'canvas_development'
- test:
$ docker-compose run --rm -e RAILS_ENV=test web bin/rails runner \
'puts ActiveRecord::Base.connection.current_database'
=> 'canvas_test'
- set a custom database name:
$ docker-compose run --rm \
-e RAILS_ENV=test \
-e CANVAS_DATABASE_TEST=canvas_rails3_ \
web bin/rails runner \
'Rails.application.load_tasks; \
Rake::Task["db:create"].invoke; \
puts ActiveRecord::Base.connection.current_database'
=> 'canvas_rails3_'
flag = none
Change-Id: Ia19038586508dc91c6a4d4386d812752e00a4ad6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/235642
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
Reviewed-by: Augusto Callejas <acallejas@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: Derek Bender <djbender@instructure.com>
This patchset removes the much duplicated database.yml and instead
defaults to a DATABASE_URL scheme. There is however still present a
docker-compose/config/new-jenkins/database.yml file to temporarily allow
our internal portal service to still function until such time we can
reconfigure it.
To set up custom connection options all that is needed is setting
DATABASE_URL. See examples of this in docker-compose.yml and
docker-compose.new-jenkins.yml.
Test Plan
=========
Image:
- pulling canvas-lms:master image boots without database errors
Repo:
- given default dev environment where
COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml
- build the web and postgres images: docker-compose build web postgres
(feel free to comment out `yarn install` and `compile_assets` in the
Dockerfile since we won't be needing them for this test and this
speeds things up)
- set a custom DATABASE_URL to change the database name and echo it to
see it gets into the image correctly:
$ docker run -it -e \
DATABASE_URL=postgres://postgres:sekret@postgres/canvas_custom_env \
$(docker-compose ps -q web) bash -c "echo \$DATABASE_URL"
=> postgres://postgres:sekret@postgres/canvas_custom_env
$ docker-compose run --rm -e \
DATABASE_URL=postgres://postgres:sekret@postgres/canvas_custom_env \
web bash -c "echo \$DATABASE_URL"
=> postgres://postgres:sekret@postgres/canvas_custom_env
- Test that setting a custom database name via DATABASE_URL can create
the database
$ docker-compose run --rm -e \
DATABASE_URL=postgres://postgres:sekret@postgres/canvas_custom_env \
web bash -c "bin/rails db:create"
=> Created database 'canvas_custom_env'
- This patchset boots on portal
Change-Id: Ic6f3819550df94b6c98b17ef05ac2029a578cfe4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234213
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Powell <spowell@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
QA-Review: Rex Fleischer <rfleischer@instructure.com>
QA-Review: Jacob Powell <spowell@instructure.com>
Product-Review: Rex Fleischer <rfleischer@instructure.com>
refs CNVS-48876
flag = none
add setting for auditors read/write paths
map settings into boolean helpers
create config values for AR writing path
split backend of event_stream by strategy
and confirm writing to both destinations functions
test dual writing from config
wrap tests around attribute mapping from
event stream to active record
dual write from all 3 auditor classes
via a shared model mixin
TEST PLAN:
* update dynamic settings to include dual write pattern
* login a few times
* publish a course
* grade an assignment
* make sure new auditor records are in cassandra
(auditors API calls is fine)
* make sure companion records are in the auditor postres table
(auditor_authentication_records,
auditor_course_records,
auditor_grade_change_records)
Change-Id: I9b85fc926f7363876f89c82a3fdceb253244fb57
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234334
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes APM-16, APM-20
flag = none
also adds context id and user id
to request annotations for APM
configures host-level sampling
TEST PLAN:
* enable apm collection on datadog agent on single test cluster
* push consul config to same cluster for enabling apm sampling
* push consul config depressing host sampling rate to 5%
* delayed job telemetry should show up in ddog
* trace count from active clusters should drop by an order of magnitude
Change-Id: I94d97b299ed14403e8b141629740a1627310b259
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/230592
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: David Warkentin <dwarkentin@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes APM-7, APM-8
flag = none
hardcode set to a very low % of client sampling by default
to keep performance impact low.
test plan:
* make sure telemetry is arriving in datadog APM
* ensure trace traffic level is low, only from one cluster
(proves settings are working)
* canvas should not show degradation in response times post deployment
Change-Id: Ifca8d3f6239d6c4e70098dd2b68b9c2a1950e121
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/230064
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
Closes: CCI-261
The mdillon repo was an unofficial postgis repo, there is now and
official postgis/postgis repo!
https://registry.hub.docker.com/r/postgis/postgis/https://github.com/postgis/docker-postgis
Test Plan:
- First, take notice if you currently have pg_collkey installed:
$ docker-compose run --rm postgres psql -x \
-h postgres
-U postgres
-d canvas
-c "SELECT * FROM pg_available_extensions WHERE \
pg_available_extensions.name = 'pg_collkey';"
If `installed_version` is blank, then the extension is not isntalled
into the `canvas` database.
- take down any running environment:
$ docker-compose stop && docker-compose down
- copy (or update) new settings from docker-compose.override.yml:
# manual diff
$ diff config/docker-compose.override.yml \
docker-compose.override.yml
# overwrite any existing config
$ cp config/docker-compose.override.yml .
- copy (or update) new settings from database.yml:
# manual diff
$ diff docker-compose/config/database.yml config/database.yml
# overwrite any existing config
$ cp docker-compose/config/database.yml config/
- rebuild and startup the postgres image:
$ docker-compose up --build postgres
- the postgres logs do not mention
ERROR: could not access file "$libdir/collkey_icu.so":
No such file or directory
- install the extension if it wasn't previously present:
$ docker-compose run --rm postgres psql -x \
-h postgres \
-U postgres \
-d canvas \
-c "CREATE EXTENSION IF NOT EXISTS pg_trgm SCHEMA public;
CREATE EXTENSION IF NOT EXISTS postgis SCHEMA public;
CREATE EXTENSION IF NOT EXISTS pg_collkey SCHEMA public;"
$ docker-compose run --rm postgres psql -x \
-h postgres \
-U postgres \
-d canvas_test \
-c "CREATE EXTENSION IF NOT EXISTS pg_trgm SCHEMA public; \
CREATE EXTENSION IF NOT EXISTS postgis SCHEMA public; \
CREATE EXTENSION IF NOT EXISTS pg_collkey SCHEMA public;"
- pg_collkey is now present:
$ docker-compose run --rm postgres psql -x \
-h postgres
-U postgres
-d canvas
-c "SELECT * FROM pg_available_extensions WHERE \
pg_available_extensions.name = 'pg_collkey';"
$ docker-compose run --rm postgres psql -x \
-h postgres
-U postgres
-d canvas_test
-c "SELECT * FROM pg_available_extensions WHERE \
pg_available_extensions.name = 'pg_collkey';"
- Optionally, Build the postgres container with fresh volumes:
$ COMPOSE_PROJECT_NAME=<a-unique-name> docker-compose --build \
up postgres
- The postgres logs show no errors related to collkey_icu.so
(like above)
Change-Id: I4f0e027cd908fee937b6204cd3a20e5ecf998021
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/228190
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Reviewed-by: Jacob Powell <spowell@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: Derek Bender <djbender@instructure.com>
Currently it appears pg_collkey throws an error in the postgres
container, althought it doesn't appear to halt the process. Adding this
missing file resolves this problem
Fixes: CCI-252
Test plan:
- docker-compose build postgres
- docker-compose up -d
- docker-compose logs -f --tail=100 postgres
- visit http://canvas.docker/ in the browser
- the postgres logs should no longer contain a message like:
ERROR: could not access file "$libdir/collkey_icu.so": No such file or
directory
feature_flag = none
Change-Id: Ib1483a24e705260b2eaeba81ec456ed9f6acf89d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/227805
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Derek Bender <djbender@instructure.com>
Product-Review: Derek Bender <djbender@instructure.com>
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Reviewed-by: Jacob Powell <spowell@instructure.com>
refs CCI-234
test plan:
- using default COMPOSE_FILE:
- docker-compose build --no-cache --pull postgres
flag = none
Change-Id: Ifa6f23a6e91dc19404795f9bd8b11d7d775d883e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/226810
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Jim Simon <jsimon@instructure.com>
Reviewed-by: Jacob Powell <spowell@instructure.com>
Reviewed-by: Laura Gonzalez-Horwitz <lgonzalez-horwitz@instructure.com>
Product-Review: Jared Crystal <jcrystal@instructure.com>
Next step will be to integrate a secrets API a-la-dynamic settings
test plan:
- Specs pass
Change-Id: Ic2fdd2be3c7f665804627f3ef3ffb5bc408d135b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/224281
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
References OUT-3442
Test Plan
:qa-cr:
Change-Id: Icd4bb2a80e9133196ee4d760f6fc1084ac7a438e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/221319
Reviewed-by: Augusto Callejas <acallejas@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Frank Murphy <fmurphy@instructure.com>
QA-Review: Augusto Callejas <acallejas@instructure.com>
wait-for-it script was left out from the postgres directory after
the update to the Dockerfile that relies on it. Adding the script
in that directory so our Dockerfile builds correctly.
Change-Id: I1c445937ff809877a7063a37eb5b1052e3ae5af5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/217588
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
Closes: CCI-2
Test Plan:
- specs that require pg_collkey are ran in new jenkins
Change-Id: I530373f9855d124dfc3c302e0d340f6217b8f33a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/215422
Reviewed-by: S. Jacob Powell <spowell@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
QA-Review: Derek Bender <djbender@instructure.com>
Product-Review: Derek Bender <djbender@instructure.com>
there are some bugs in the newest version causing spec failures.
Change-Id: I5b2864815f552831d273b74843e129228b581f55
Reviewed-on: https://gerrit.instructure.com/211810
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
this will get us up to chrome 77
Change-Id: I930a5a6d82f30d4fed0d8072a4cbec4e43742056
Reviewed-on: https://gerrit.instructure.com/211116
Tested-by: Jenkins
Reviewed-by: S. Jacob Powell <spowell@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
QA-Review: S. Jacob Powell <spowell@instructure.com>
Product-Review: S. Jacob Powell <spowell@instructure.com>
Change-Id: I30c0c0006de8779dea1743d6c626022756f05d5a
Reviewed-on: https://gerrit.instructure.com/210564
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
Change-Id: Id4a31fe3d3c8784b65730d7c62d3bd1ef68767ed
Reviewed-on: https://gerrit.instructure.com/210756
Reviewed-by: James Butters <jbutters@instructure.com>
Tested-by: Jenkins
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
instead of replacing the originals in the image
Change-Id: Ibb32bb32cf2487cf17eb4688eea30d19400b02a7
Reviewed-on: https://gerrit.instructure.com/210409
Tested-by: Jenkins
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
RedisStore is no longer supported
somewhat surprisingly, the serialization formats are compatible, so we don't
need to do any namespacing
Change-Id: Iede3a023cada95313875f0ce419b649c364ee97c
Reviewed-on: https://gerrit.instructure.com/202663
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Test Plan:
Using docker canvas verify you can hit the
/api/lti/security/jwks endpoint and see three JWKs
Change-Id: I687cec8012f4ebfd1d9319e65b52343e6bae89bb
Reviewed-on: https://gerrit.instructure.com/188823
Tested-by: Jenkins
QA-Review: Marc Phillips <mphillips@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Reviewed-by: Marc Phillips <mphillips@instructure.com>
closes CORE-2329
There were some tests that were expecting a snapshot-like value
where it expected `new Date().toLocaleDateString()` to give something
Like “2016-7-11” but that was actually wrong. If you do
`new Date().toLocaleDateString()` in a browser it will give you
something like “7/11/2016”. And this new version of node matches what
a real browser would have done, so I just updated the specs so they
are looking for the correct format. This change does not actually
reflect a change in what a real user would see. Just what
jest/jsdom/node formats it as.
Test Plan:
- check to make sure that the assignments 2 availability dates
component produces markup exactly as it did before
- Automated tests pass
- Build canvas locally, everything passes.
- Build canvas with docker, everything passes.
Change-Id: I74285cd6d9b251ca60ab79396e332cc3a419bcee
Reviewed-on: https://gerrit.instructure.com/177198
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Previously the jwk set_keys was not pointing to any
data_center when it makes the call to set the keys.
This now will grab the configuration from consul of
the dc and set it as the data_center to put to.
ref PLAT-3361
Test Plan:
n/a
Change-Id: I70e3cfb52ba557543ad203c516739a18cae17c26
Reviewed-on: https://gerrit.instructure.com/159839
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Tested-by: Jenkins
Product-Review: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Marc Alan Phillips <mphillips@instructure.com>
Closes PLAT-3633, PLAT-3634
Test Plan:
- Do an LTI 1.3 launch in Canvas and verify the id token is
signed with the current canvas secret key.
- Verify the following claims are included and correct:
* exp
* iat
* iss
* nonce
* sub
Change-Id: I57699ac42bbe98a9fa03f82f3f9b9a16c6923011
Reviewed-on: https://gerrit.instructure.com/159855
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Marc Alan Phillips <mphillips@instructure.com>
Product-Review: Marc Alan Phillips <mphillips@instructure.com>
Added lti JWK config for local development purposes using
LTI 1.3. Works with local and docker development.
closes: PLAT-3505
Test Plan:
n/a
Change-Id: Ib45f33d11027c608d6eb2397d29af6ef1878b2a7
Reviewed-on: https://gerrit.instructure.com/154194
Tested-by: Jenkins
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Product-Review: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Marc Alan Phillips <mphillips@instructure.com>
Change-Id: I2e5c1be87cb3e88a203379127891ed4b6782fc26
Reviewed-on: https://gerrit.instructure.com/145756
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
Tested-by: Jenkins
Product-Review: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Marc Alan Phillips <mphillips@instructure.com>
closes MBL-9792
test plan:
- make a request to /api/v1/users/:id/pandata_token
with param 'app_key' of value 'IOS_pandata_key'
- make the same call with a value of 'ANDROID_pandata_key'
- both should return a 200 code
and a json object with a 'token' and a 'expires_at'
Change-Id: If993ad3c49b89a61ef8caa91d5f347250998070b
Reviewed-on: https://gerrit.instructure.com/144535
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Cameron Sutter <csutter@instructure.com>
If you are getting errors about “The engine "node" is incompatible with
this module. Expected version ">=8.9.4”.” after applying this change,
It means you need upgrade your node to 8.9.4. to do so:
if you use nvm: `nvm install` inside the canvas dir
If you use brew: `brew upgrade node`
If you use apt-get: see https://github.com/nodesource/distributions
If you use docker: rebuild your docker container
Closes: CORE-704
Test plan:
* js tests should pass
* webpack and brandable_css should generate the exact same
CSS and JS output as before.
* all of our build tooling, including docker stuff, should continue
to work and use Node 8.
If you know of something else that needs to be updated to use node 8
everywhere, let me know
Change-Id: Ic019710c219d8b8c627ce03e0dffde731cfa2856
Reviewed-on: https://gerrit.instructure.com/136802
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Probably broken by the release of PG 10, but it could be something else.
test plan:
- Check out the commit
- Try `dc build --no-cache postgres`
- It should successfully build
Closes gh-1136
Change-Id: I78772a60cbf85ba1fa93957ecb6651e8f1b60068
Reviewed-on: https://gerrit.instructure.com/129878
Reviewed-by: Bryan Petty <bpetty@instructure.com>
Product-Review: Bryan Petty <bpetty@instructure.com>
QA-Review: Bryan Petty <bpetty@instructure.com>
Tested-by: Jenkins
Fixes: CNVS-39293
Since we eliminated the pre-population functionality from our Consul
wrapper we needed something to conveniently populate the KV store.
Test Plan:
- Start a Consul server
- Run `bin/rake canvas:seed_consul`
- Verify that values were written to the KV store.
Change-Id: I340011b7d00ed4e3dd2918e3f101f6377fc72d7e
Reviewed-on: https://gerrit.instructure.com/126574
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Tyler Pickett <tpickett@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
fixes: GRADE-243
Allow cassandra's data to persist after using `docker-compose down
cassandra` where before this command would effectively wipe your database
This is in line with how the pg_data volumes work.
test plan:
- setup cassandra
- create a keyspace
- run `docker-compose down && docker-compose up -d` (-d for daemon)
- the previously create keyspace still exists
Change-Id: Ib58bec022eda79ad45352419e4fd33b07af7cf21
Reviewed-on: https://gerrit.instructure.com/124278
Tested-by: Jenkins
Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com>
Reviewed-by: Matt Taylor <mtaylor@instructure.com>
QA-Review: KC Naegle <knaegle@instructure.com>
Product-Review: Derek Bender <djbender@instructure.com>
Test plan: docker-compose run --rm karma yarn test
Change-Id: I316d80e7a1b712b0dda91a390c4dddeb09b3e6fb
Reviewed-on: https://gerrit.instructure.com/122776
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Fixes: CNVS-35833
There is a lot more than just moving to Consul going on here. The whole
PrefixProxy business wouldn't be required for this change, but it will
be really useful as we move to adding cluster awareness.
Test Plan:
- Have MathMan running
- Update config/consul.yml to enable use_for_svg and
use_for_mml under the math-man init values key
- Start Canvas
- Build an equation with the rich content editor
- The equation should be rendered as usual.
Change-Id: I650527ebaecb6224c6ee6ba26346d27dee33b9d7
Reviewed-on: https://gerrit.instructure.com/111543
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Tyler Pickett <tpickett@instructure.com>
bring the development docker image down from 3.6GB -> 2.4GB
add a production docker image that weighs in at 1.2GB, which should speed
up end-to-end tests
template-ize web Dockerfiles so that common stuff stays consistent, volume
dirs are set up properly, etc.
test plan:
1. docker-based builds should pass
2. docker image should be usable (docker-compose up, etc)
Change-Id: I41ebb155090f66e346bdc285ca5c613ee5793127
Reviewed-on: https://gerrit.instructure.com/112859
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Fixes: CNVS-35832
Refs: CNVS-32864
This was super simple because of the change to using a hash for
configuring LiveEvents instead of a PluginSetting object
Change-Id: Ia34cb905e22a21c822f48b581e3e3cd4f7a738d3
Reviewed-on: https://gerrit.instructure.com/110193
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Tyler Pickett <tpickett@instructure.com>
Also, make Consul container accessible from the host.
Fixes: CNVS-35831
Refs: CNVS-34341, CNVS-32864
Test Plan:
- Smoke test RCS and Canvas running together to make sure they still
play nice.
Change-Id: I418d54a176677b1df8ec42a009752807908a847c
Reviewed-on: https://gerrit.instructure.com/99443
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Tyler Pickett <tpickett@instructure.com>
fixes CNVS-35005
Test Plan
1. run: docker-compose build
2. run: docker-compose run --rm web bundle exec rake db:migrate:redo VERSION=20120502190901
3. Visit: /accounts/1/users
4. Create users with the names: Jalapeno, Jalapeoo, Jalapeño, JalapeЖo
5. Refresh the page and verify they are sorted:
Jalapeno, Jalapeño, Jalapeoo, JalapeЖo
6. Create an assignment
7. Give each of the students created above a grade
8. Visit: /courses/1/gradebook/history
9. Click on the assignment name to display the hidden table.
10. Verify the table of students / grades is sorted:
Jalapeno, Jalapeño, Jalapeoo, JalapeЖo
Change-Id: I9743c559a20a3d50600bcbc7e4a310105ec638cf
Reviewed-on: https://gerrit.instructure.com/102465
Tested-by: Jenkins
Reviewed-by: Neil Gupta <ngupta@instructure.com>
QA-Review: Anju Reddy <areddy@instructure.com>
Product-Review: Keith T. Garner <kgarner@instructure.com>
fixes PLAT-2080 PLAT-2059 PLAT-2061
Test plan:
* Set up canvas
* To be able to talk to http://les.docker
* To use an encryption key and signing secret that are 32 bytes long
* Set up live events subscription service
* To use the same signing secret you used in canvas and a base64
encoded version of the encryption key you used in canvas
* Run docker-compose run --rm app npm run seed:dynamo and give it the
developer key you want to use for testing
* With the subscription service running open up a rails console in Canvas
and run the following:
ToolProxy = Struct.new("ToolProxy", :guid, :product_family)
Family = Struct.new("Family", :developer_key)
f = Family.new(<a developer key>)
tp = ToolProxy.new('hahahah', f)
res = Services::LiveEventsSubscriptionService.tool_proxy_subscriptions(tp)
* Ensure that you get a response back with the subscriptions for your
developer key
* Go through this process first with dynamic settings enabled and then
with consul enabled
Change-Id: I454d5a82d98ce1edb2bd9afd23cb974dc062e04f
Reviewed-on: https://gerrit.instructure.com/100072
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Andrew Butterfield <abutterfield@instructure.com>
This only applies for local development
An OPS ticket will need to be made for configuring production/beta
fixes PLAT-2079 PLAT-2064
Test plan:
* Run the following command
cp config/dynamic_settings.yml.example config/dynamic_settings.yml
* Open up a rails console and run
Canvas::DynamicSettings.from_cache('live-events-subscription-service', expires_in: 5.minutes)
* Ensure that a settings hash is returned with the url for a local,
dockerized subscription service
* Remove the config/dynamic_settings.yml
* Add config/consul.yml either by copying config/consul.yml.example or
docker-compose/config/consul.yml.example
* Configure docker compose to use consul
* Open up a rails console and run
Canvas::DynamicSettings.from_cache('live-events-subscription-service', expires_in: 5.minutes)
* Ensure that a settings hash is returned with the url for a local,
dockerized subscription service
Change-Id: I495cc73d914cbefd409fed5ec7ad6cebd0f8c200
Reviewed-on: https://gerrit.instructure.com/99797
Tested-by: Jenkins
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Andrew Butterfield <abutterfield@instructure.com>
The lti_test_tool_common file is no longer needed as the
selenium test automation work is going to happen in a
separate repo to keep from polluting canvas with external
micro-services.
test plan:
tests should still pass
Change-Id: If657c8ba98bfb54e5ab57faf3b1c016edf908d6a
Reviewed-on: https://gerrit.instructure.com/96765
Tested-by: Jenkins
Reviewed-by: Pedro Fajardo <pfajardo@instructure.com>
Product-Review: August Thornton <august@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Docker entrypoints can't be executed unless they are set as executable.
Also fixes a few other discrepancies:
- adds common docker-compose.local.*.yml to .dockerignore
- updates docs for enabling phantomjs-tests container
- mount common volumes for js-tests and phantomjs-tests containers
Test Plan:
1. Enable phantomjs-tests and js-tests docker containers.
2. docker-compose build --pull
3. Ensure phantomjs-tests and js-tests containers work.
Change-Id: I1ab20575f9936b6cfc2c61501441b1137c9df4cb
Reviewed-on: https://gerrit.instructure.com/95690
Reviewed-by: Brad Horrocks <bhorrocks@instructure.com>
Reviewed-by: Michael Brewer-Davis <mbd@instructure.com>
Tested-by: Jenkins
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Bryan Petty <bpetty@instructure.com>
If you have a docker-compose.override file you'll want to
move it somewhere else.
mv docker-compose.override.yml docker-compose.`whoami`.yml
Once you've updated your override file to the version 2 syntax, you
should add it to the COMPOSE_FILE environment variable. Probably in a
.env file in the project root.
Test plan:
You'll need to remove your existing canvas containers and volumes to
fully test this.
to do so run this **BEFORE** you checkout this patchset
```
docker-compose down
docker-compose ps -q | docker rm
docker volume ls -q | grep canvaslms | xargs docker volume rm
```
then you should be able to get up and running using the following
```
cp docker-compose/config/* config/
dc build
dcr web bundle exec rake db:create db:initial_setup
dc up
```
You should be able to access canvas like normal
Change-Id: Ia7ff76cfdd4f46278fc1cb2a03969fdadaa4a434
Reviewed-on: https://gerrit.instructure.com/91008
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brad Horrocks <bhorrocks@instructure.com>
this changes the name of the canvas gem volume, so you'll need to run:
docker-compose run --rm web bundle install
after applying this change. you may also want to run:
docker volume rm canvas-gems
to delete the old gem volume, which will no longer be used.
closes CNVS-33086
test plan:
- docker-compose run --rm web bundle install
- docker-compose up
- things should work
Change-Id: Iace97ca723c9e56a5d252a2a5f447f3196487d0a
Reviewed-on: https://gerrit.instructure.com/94311
Tested-by: Jenkins
Reviewed-by: Benjamin Christian Nelson <bcnelson@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
closes CNVS-33090
test plan:
- start with a fresh dinghy and fresh canvas-lms repo
- follow Canvas Docker Installation Guide in the wiki
- after canvas-compose up , login to your account on your local setup
- navigate to Admin > ACCOUNT > Settings > Feature Options and turn on
"User Remote Version of Rich Content Editor..." options
- navigate to Dashboard , then navigate back to Admin > ACCOUNT > Settings
- rejoice that you do not get the "key length too short" CipherError
Change-Id: Ia4503fcfcafed00aab5616428d86fb41955d7ab3
Reviewed-on: https://gerrit.instructure.com/94383
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Product-Review: brian kirkby <bkirkby@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
test plan:
- rebuild a docker container based on the canvas Dockerfile from scratch
- it should work
Change-Id: I096d33a73a5d2679a4e6d3c64ba2264d8274ed1d
Reviewed-on: https://gerrit.instructure.com/94024
Reviewed-by: Benjamin Christian Nelson <bcnelson@instructure.com>
Reviewed-by: Alex Ortiz-Rosado <aortiz@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Tested-by: Jenkins
Product-Review: Simon Williams <simon@instructure.com>
Fixes CNVS-31618
Test plan:
1. copy the updated config/consul.yml into your config directory
2. make sure api specs pass in docker
(eg docker-compose run --rm web rspec spec/apis/v1/grading_periods_api_spec.rb)
Change-Id: Ib80c01d2770c216aa846362e3ea2efbfde5f5e63
Reviewed-on: https://gerrit.instructure.com/89692
Reviewed-by: Derek Bender <djbender@instructure.com>
Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com>
Tested-by: Jenkins
QA-Review: Derek Bender <djbender@instructure.com>
Product-Review: Neil Gupta <ngupta@instructure.com>
closes: CNVS-29725
this gets everything working on node 6.
As far as our build process goes, it cannot support
running on both node 6 at the same time as 0.12
since our i18nliner handlebars stuff uses jsdom and
one version of it only works on node <4 and the
next only works on 4+.
But the stuff in the production dependencies in
package.json, aka the stuff that runs on the job
servers (brandable_css), can work on both. we just
need to run npm rebuild on the job servers if the stuff
that was npm installed into ./node_modules was compiled
against a different version of node. that is done here:
https://gerrit.instructure.com/81254
that commit needs to be committed to caturday before
we commit and deploy this to beta
as far as managing node, there are 2 "official"
ways that will make you life easier, you can either
just use docker or use nvm (https://github.com/creationix/nvm)
if you use nvm and if you use ZSH:
Put this into your $HOME/.zshrc to call nvm use automatically
whenever you enter a directory that contains an
.nvmrc file with a string telling nvm which node to use:
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc() {
if [[ -f .nvmrc && -r .nvmrc ]]; then
nvm use
elif [[ $(nvm version) != $(nvm version default) ]]; then
echo "Reverting to nvm default version"
nvm use default
fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc
but however you do it, as long as you have node 6.2
installed it should work
test plan:
* install nvm
* check this patchset out
* run bundle exec rake canvas:compile_assets
* it should work
* use theme editor to preview a change to a theme
* it should work
Change-Id: I1cc9faed361938afc713c4b921042386b956db70
Reviewed-on: https://gerrit.instructure.com/80839
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This is required by the QTI import tool.
Change-Id: I2092ef99f86b05d29856ed19e1f0c703406c999e
Reviewed-on: https://gerrit.instructure.com/85542
Tested-by: Jenkins
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
When the gem volume gets created on linux, it gets created with root
permissions. This causes issues on linux because the docker user (id
9999) cannot write to it when it installs gems.
By creating the directory that the volume gets mounted to in the
Dockerfile, the volume will assume the same permissions/ownership and
thus will get ownership on the host system as user 9999
Change-Id: I61a04c38dd7f4f6f526746a0d3ddab2a15549f1c
Reviewed-on: https://gerrit.instructure.com/84432
Tested-by: Jenkins
Reviewed-by: Zach Wily <zach@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
QA-Review: Benjamin Porter <bporter@instructure.com>
Changes:
- Uses standalone selenium node (meant for use without hub).
- Selenium node upgraded from 2.45.0 to 2.53.0.
- Upgrades Firefox from 34.0 to 45.0 (uses upstream version now).
- Clarify docker docs for running selenium specs a bit.
- Enable use of selenium container on checkout without changes.
- No longer requires link in web container.
- Requires dinghy/dory though for proxy, but it already did.
- Fixes /tmp/.X99-lock issue on container re-use.
Change-Id: I31793103e62022dea227b181a738383788660f6d
Reviewed-on: https://gerrit.instructure.com/83193
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
because we control what version of bundler is installed, we uninstall
the version provided by the base image and install the version we
expect to be there. however, if the base image installs bundler to a
system gem directory, an extra option must be provided to the
uninstall command. this is an issue as we are attempting to have the
base image install bundler system-wide.
Change-Id: I0b21e557315ed4ce7382efe3d740b602b016054d
Reviewed-on: https://gerrit.instructure.com/75328
Tested-by: Jenkins
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Product-Review: Mark Severson <markse@instructure.com>
QA-Review: Mark Severson <markse@instructure.com>
fixes CNVS-9516
For account level roles that don't have the manage permission, you
should not be able to change the weight etc via the cog menu on the
assignments page. This commit ensures only users that have the manage
permission can see the cog.
Test Plan
Setting Up a User -----
1. Create a new account role (something like TestAdmin)
2. Set permissions on that role to manage and view assignments but NOT
manage a course
3. Create a new user from the admin section with that role
4. Become that user to test this
------
Given you are an account level user with the mangage_courses permission
set to true
When you go to the assignments page
Then you should see a cog menu with the weight form in it
Given you are an account level user with the mangage_courses permission
set to false
When you go to the assignments page
Then you should NOT see an admin cog menu with the weight form in it
Change-Id: I64179f247e83647b11f7f1d34358d9d31023f2e8
Reviewed-on: https://gerrit.instructure.com/72919
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Tested-by: Jenkins
Product-Review: Sterling Cobb <sterling@instructure.com>
This image is an appliance more in line with the postgres or redis
images, so it manages its own data volume. Thus the docker-compose and
doc file changes.
Change-Id: I8f435400bd8427313d0bc290c84cd44639ead074
Reviewed-on: https://gerrit.instructure.com/71502
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
fixes PLAT-1330
test plan:
you should be able to build and run the docker image
Change-Id: I4620cba9f6b4378d0677e1e500c367422187a27d
Reviewed-on: https://gerrit.instructure.com/71678
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Product-Review: August Thornton <august@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins
This removes our custom-built consul docker container (only used in
development) and replaces it with a popular public image from the docker
registry.
Change-Id: I7d42117e704f60b99f8e7f2895e9fb1b029c15f2
Reviewed-on: https://gerrit.instructure.com/71511
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Jenkins
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Change-Id: I2e24741a2cfbd6d2a3ba16739fc68a6a807c601c
Reviewed-on: https://gerrit.instructure.com/69909
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Jon Willesen <jonw@instructure.com>
QA-Review: Jon Willesen <jonw@instructure.com>
our docs say that you just copy over your config files and you're
ready to start docker-ing, so we should make sure there's a consul
config file entry
TEST PLAN:
1) no production changes (does not touch app code)
2) clean install, clean config directory
3) copy docker-compose/config/ files to your config directory
4) you shouldn't be missing any config files when you start your
compose file up
Change-Id: I5c3fc2ec1e537355bd9a4c5a8b36640349b822cf
Reviewed-on: https://gerrit.instructure.com/70327
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-26216
canvas requires a later bundler version than before
TEST PLAN:
1) should be able to start a rails console without bombing due to
bundler version
Change-Id: I93f94f6e1afbd153668a2d9b5bbbc672840a065d
Reviewed-on: https://gerrit.instructure.com/69742
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Ethan Vizitei <evizitei@instructure.com>
Building of fonts fails unless we have sfnt2woff
Test Plan:
- Make sure image is built successfully
- Make sure the following command succeeds:
- docker-compose run --rm web bundle exec fontcustom compile --force
Change-Id: Ie7fa7e701584894ee5fd6d1eea7d4144c512b5bf
Reviewed-on: https://gerrit.instructure.com/69103
Tested-by: Jenkins
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
There is a simpler (and faster) way to set the locale properly inside
the ruby:2.1 image.
Test Plan:
- Make sure the build succeeds and the locale is set properly
Change-Id: I1f1b7fb8f723f1c46b3f44e357789ae313513c2d
Reviewed-on: https://gerrit.instructure.com/68728
Tested-by: Jenkins
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Ryan Taylor <rtaylor@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
refs CNVS-24816
create the feature flag and expose it in
the Eportfolios controller
Add a consul docker container to docker-compose.yml,
and a class for consuming settings in consul.
Also, add the ability to init config values
into consul from the consul.yml file
TEST PLAN:
1) edit your consul.yml to look kinda like this:
development:
host: consul
port: 8500
ssl: false
init_values:
rich-content-service:
app-host: rce.docker
cdn-host: rce.docker
2) go to edit an eportfolio as a logged in user
3) check in js console "ENV.RICH_CONTENT_SERVICE_ENABLED"
4) should be "true" or "false" depending on the feature
flag state for that user's root account
5) with the feature flag on, refresh and check the env
6) should have values in the env for
RICH_CONTENT_APP_HOST and RICH_CONTENT_CDN_HOST
Change-Id: Ic138e24416b2aadd965ce4811d3c56538de391bc
Reviewed-on: https://gerrit.instructure.com/66614
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
Test Plan: Make sure that bundle install in the web container succeeds
Change-Id: I67af24cab8948e367e513068ec4d434b7388e883
Reviewed-on: https://gerrit.instructure.com/67018
Reviewed-by: Alex Kovshovik <akovshovik@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Porter <bporter@instructure.com>
Tested-by: Benjamin Porter <bporter@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
closes CNVS-24124
makes working with web pack possible in canvas
instead of require-js. See doc/working_with_webpack.md
for instructions.
TEST PLAN:
Nothing should change in non-webpack'd behavior
Things should mostly work when you use the
USE_WEBPACK environment variable, but make sure to document
and ticket things that don't
Change-Id: I493a259a609e9e183950bc57aa5876df70108547
Reviewed-on: https://gerrit.instructure.com/64386
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes RC-70
I was continuing to error with this:
kinesis_1 | LevelUPError: Failed to require LevelDOWN (Cannot find module 'leveldown/package'). Try `npm install leveldown` if it's missing
Adding the npm install command to the Dockerfile for
kinesis seemed to solve the problem.
Change-Id: I963e97761c966492fca8b3d8eec607d628902af9
Reviewed-on: https://gerrit.instructure.com/59966
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Jenkins
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
This is another attempt to fix selenium spec reliability. Without this
change, when doing a `get` on a URL, we weren't waiting for the new page
to actually load before doing our checks. This leads to stale element
errors, etc.
We do have to be sure to *not* wait for a new page load if the target
URL is the same as the current URL, but with a different hash.
Running the following command:
```
for i in $(seq 10); do
echo "**** $i"
bundle exec rspec -e "moving outcomes tree should move a learning outcome group via tree modal" spec/selenium/
done
```
would fail at least half the time without this patchset, and never fails
with it (in my testing).
Change-Id: I2d707f96d7713f69be865355d8a78bad1261d446
Reviewed-on: https://gerrit.instructure.com/53211
Tested-by: Jenkins
Reviewed-by: Zach Wily <zach@instructure.com>
Product-Review: Zach Wily <zach@instructure.com>
QA-Review: Zach Wily <zach@instructure.com>
The leading dot is nginx syntax for allowing both `canvas.docker` and `*.canvas.docker`
Also pull in libxmlsec1-dev, for SAML.
Change-Id: I4281252053b7d890b08c06c30ad17f5b11670579
Reviewed-on: https://gerrit.instructure.com/52720
Tested-by: Jenkins
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Charley Kline