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>
fixes: CCI-159
flag = none
Test-Plan:
dont add a flag here and make sure it links in builds.
Change-Id: I7c424cc66c17de33982639650ed9167a1c762b7d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/220944
Tested-by: Jenkins
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
Reviewed-by: Derek Bender <djbender@instructure.com>
QA-Review: Rex Fleischer <rfleischer@instructure.com>
Product-Review: Rex Fleischer <rfleischer@instructure.com>
fixes KNO-140
flag=none
Test Plan:
- commit or modify a migration file
- notice gergich -1 your commit and leaves a comment
- tests still pass
- celebrate
Change-Id: Ic5b353c1750f65c7de988fc6ce9ed68f16db352f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/219997
Tested-by: Jenkins
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
fixes: CCI-73
flag=none
Test-Plan:
push the commit without a flag, then do it with and
ensure the gergich messages are correct
Change-Id: I28b6691482e01547f7ffdc50c70123a329e195b5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/219403
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Rex Fleischer <rfleischer@instructure.com>
Product-Review: Rex Fleischer <rfleischer@instructure.com>
This is in an attempt to
1. Prevent unpredictable behavior when
running docker-compose without specifying
docker-compose files (intentionally or
unintentionally *This is exactly a problem
I found that caused issues, running the defaults on accident)
2. Follow more closely what other projects
are doing, they don’t have the override committed
3. Follow typical industry standard,
from what I’ve seen, such as
https://blog.sentry.io/2019/02/28/exception-perceptions-docker
test plan:
Running ./script/docker_dev_setup.sh with no
docker-compose.override.yml
in the root directory will print the message
"Copying default configuration from
docker-compose.override.yml.example to
docker-compose.override.yml" and copy the file in.
Running ./script/docker_dev_setup.sh with an existing
docker-compose.override.yml will simply print
"docker-compose.override.yml exists, skipping
copy of default configuration"
Also check that the documentation changes
sufficiently explain the new
process and what to expect.
The file shouldn't be in the root of the
directory in the repo anymore,
in order to prevent unwanted default behavior
(requires explicit naming
of docker-compose files)
There should be a
docker-compose.override.yml.example in the config
folder for reference.
• Add `docker-compose.override.yml` to `.gitignore`
• Leave a copy of the current
`docker-compose.override.yml` in
`config/docker-compose.override.yml.example`
• Delete `docker-compose.override.yml`
from the root directory
fixes CORE-3409
Change-Id: I9cffeb52f2cc233061f78de10fcb240c09743542
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/214116
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
Reviewed-by: Robert Lamb <rlamb@instructure.com>
QA-Review: S. Jacob Powell <spowell@instructure.com>
Product-Review: S. Jacob Powell <spowell@instructure.com>
test plan:
- shutdown dinghy if already running:
$ dingy down
- backup ~/.dinghy:
$ cp -r ~/.dinghy ~/.dinghy.bak
- delete existing config:
$ rm -rf ~/.dinghy
- setup a different machine name in preferences.yml:
$ cat ~/.dinghy/preferences.yml
---
:preferences:
:create:
# 'virtualbox' if you are not using docker-machine-driver-xhyve
provider: xhyve
:machine_name: dinghy-memory-test
- create the dinghy vm (outside of the docker_dev_setup.sh script):
$ dinghy create
- set temporary shell variables:
$ eval $(dinghy env)
- verify ram is less than 8GB
$ docker-machine inspect dinghy-memory-test | ruby -r json -e 'puts JSON.parse(ARGF.read).fetch("Driver").fetch("Memory")'
2048
- verify the script exits before setting up canvas and clarifies that 8GB of
memory is required:
$ ./script/docker_dev_setup.sh
<snip>
Canvas requires at least 8GB of memory dedicated to the VM. Please recreate
your VM with a memory value of at least 8192. For Example:
$ dinghy create --memory 8192
- remove the tempory dinghy vm:
$ dinghy destroy
- restore dinghy configuration files
$ rm -rf ~/.dinghy
$ mv ~/.dinghy.bak ~/.dinghy
- open a new shell to restore previously set shell environment variables
Change-Id: I63fbd486b276b653bbcec017cfabb354b746bbe2
Reviewed-on: https://gerrit.instructure.com/213110
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Tested-by: Jenkins
Per https://github.com/tc39/proposal-optional-chaining
Test Plan:
- Jenkins passes
flag = none
Change-Id: I7b9fde7e91a9bd00a85397bcf791b8eccd528a5b
Reviewed-on: https://gerrit.instructure.com/209826
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
The previous commit makes it so i18nliner can understand <> instead of
<React.Fragment>, so this turns back on the eslint rule we had to turn
Off
Test plan:
* run bin/rake i18n:generate_js (or let the Jenkins builds run)
* it should pass
Change-Id: Ia3204cd6c3147eb52ca612adbb3b20b2df8c6921
Reviewed-on: https://gerrit.instructure.com/205378
Tested-by: Jenkins
Reviewed-by: Ed Schiebel <eschiebel@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
also keeps it undocumented for now
test plan:
* test an lti launch in a course using a variable
in the format:
$Canvas.membership.permissions<permission1,permission2,..>
with a comma-separated list in between the brackets
corresponding to course-level permissions
(see doc/api/roles.html#method.role_overrides.show), e.g.
$Canvas.membership.permissions<read_forum,moderate_forum>
these are the list of permissions to check
when the variable is expanded it should substitute it with a
comma-separated list of permissions filtered to those
that the user has been granted within the course
closes #PLYT-1796
Change-Id: I1c039e04318fcfe8ca5ee450e608bd3fb2affe6b
Reviewed-on: https://gerrit.instructure.com/194797
Tested-by: Jenkins
QA-Review: Nathan Mills <nathanm@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Reviewed-by: Marc Phillips <mphillips@instructure.com>
This adds the creation of the coverage summary to the javascript build
for easy sub-report generation.
Change-Id: I6a5df7496d2ce32733a64f1cb2a8115dd5556495
Reviewed-on: https://gerrit.instructure.com/182785
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Keith Garner <kgarner@instructure.com>
Product-Review: Keith Garner <kgarner@instructure.com>
refs ADMIN-2277
test plan:
- Do some spot checking all around, esp. on newer stuff written with
InstUI
- Do some specific spot checking on:
- Assignments edit page. Esp. with moderated grading
- Gradebook late policies
- Check the original bug (ADMIN-2211)
Change-Id: Iaaaeb9d86dc2d59cb2c9ccca2a8764a5adb0896b
Reviewed-on: https://gerrit.instructure.com/176912
Tested-by: Jenkins
Reviewed-by: Anju Reddy <areddy@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
This only affects javascript files and only affects things
from the prettier whitelist
This will run slowly if you don't have node_modules installed
locally (e.g., in Docker), but it will gladly attempt to
run things in Docker for you.
This adds a new githook_installer image that will install
the githook whenever a docker-compose up happens in the
repo. It will also install the hook whenever a `yarn`
occurs locally (as a postinstall hook).
This commit should also not fail things. For example
having unused variables is an ESLint error, but it isn't
autofixable. It will log the error, but will otherwise
continue. However, it will make this pretty with prettier
as well as fix any other autofixable ESLint errors.
closes CORE-2118
Test Plan:
- Run `yarn`
- Add some semicolons to something from the whitelist
- git add that file
- git commit and it will strip semicolons
- In a dockerized Canvas:
- docker-compose up
- Add semicolons to a file
- git add that file
- git commit, it will take forever (~60s)
- It should have stripped out semicolons
Change-Id: Id9198aa008808e898f29acb9ed64dd14ff843222
Reviewed-on: https://gerrit.instructure.com/171510
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
This also moves us temporarily to a git branch version of xsslint until the
official package gets a new release with the appropriate fixes in place.
closes CORE-2125
Test Plan:
- Automated tests pass
- xsslint output shows that it linted many files
Change-Id: Id87e872dd2b7a08f11c0ddfaebdfc3f44e86c724
Reviewed-on: https://gerrit.instructure.com/171702
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
I guess since our team owns these we can opt them in now
Test plan:
* nothing should change
Change-Id: Ic7207e1033869ef60644c41bd5c80a3e8532a6dd
Reviewed-on: https://gerrit.instructure.com/171471
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Test Plan:
- Introduce a failing JS test
- Run `COVERAGE=1 RUN_TESTS_FIRST=true yarn run test:coverage`
- It should fail
Change-Id: I27c6c876c68ce76be2da85e0e573e2051ade1951
Reviewed-on: https://gerrit.instructure.com/169389
Tested-by: Jenkins
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
This addresses "No such file or directory" for first-time users
of script/canvas_update and script/prepare/prepare .
Test Plan:
- qa-cr
Change-Id: I65373682830c7cfb169b6d0b5436dc24542cd446
Reviewed-on: https://gerrit.instructure.com/167770
Tested-by: Jenkins
Reviewed-by: Brian Watson <bwatson@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Michael Hargiss <mhargiss@instructure.com>
We have no documentation in Confluence or this repo for running
Selenium tests natively. This commit adds a doc for that.
We're also migrating the "prepare" script from the qa_tools repo
to this one.
Test Plan:
- follow the instructions in doc/testing_with_selenium.md to
verify it's accurate
- run script/canvas_update to verify it still works
- follow the setup instructions in script/prepare/README.md and
verify it works
Change-Id: I11d63e60dc1faa8be1dfacfc9bebfcbea55c31f1
Reviewed-on: https://gerrit.instructure.com/167300
Tested-by: Jenkins
Reviewed-by: David Tan <dtan@instructure.com>
QA-Review: David Tan <dtan@instructure.com>
Product-Review: Michael Hargiss <mhargiss@instructure.com>
test plan:
when you run `yarn run upgrade-instructure-ui`,
it should put the version number it upgraded to in the commit message.
Change-Id: I8b463a12994b31d9c2ae80458b51c24d183de9ee
Reviewed-on: https://gerrit.instructure.com/161314
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Closes: CORE-1709
This is what our Jenkins job to pull in every instui RC commit will use
Test plan:
* run `yarn upgrade-instructure-ui`
* it should make a commit that has new entries in yarn.lock for all the
instUI packages that uses the latest rc version on the npm registry
* it should not affect anything else besides yarn.lock
Change-Id: I78cce6e801015819c4e4b27e26ede352deceebb9
Reviewed-on: https://gerrit.instructure.com/160435
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Fixes OUT-2367
There are now two scripts:
- docker_dev_setup.sh: will create / recreate the service
and all databases locally
- docker_dev_update.sh: can be used to migrate the local
master branch. Will also pull plugin changes and run the
relevant migrations.
Both scripts now directly use parts of canvas_update under the hood,
which will hopefully make future workflow changes less painful.
Test Plan:
- With docker:
- optional: create a new canvas checkout
(you can use a different directory name to avoid destroying your
current database)
- git fetch
- check out this gerrit, and use `git checkout -b 2367` to
create a branch for it
- git checkout origin/master~200
- git checkout 2367 -- script
- ./script/docker_dev_setup.sh (follow all prompts)
- docker-compose up -d
- login, accept the terms of use
- docker-compose down
- git checkout master
- ./script/docker_dev_update.sh -n code
- docker-compose up -d
- login, verify you are not asked for terms of use and the school name
is the same as before.
- docker-compose down
- ./script/docker_dev_setup.sh again (nuke the old database,
change the root account name)
- docker-compose up -d
- login, accept the terms of use, verify the new account name
Change-Id: Ie40600d7ea1e90633d9139b4cc1cf853695ac8f8
Reviewed-on: https://gerrit.instructure.com/151547
Tested-by: Jenkins
Reviewed-by: Michael Brewer-Davis <mbd@instructure.com>
Reviewed-by: Augusto Callejas <acallejas@instructure.com>
QA-Review: Dariusz Dzien <ddzien@instructure.com>
Product-Review: Neil Gupta <ngupta@instructure.com>
If a user has installed docker via other means, checking for docker.io
will cause apt-get to install over it and break the existing docker
installation. Since docker-compose will install docker.io recursively,
this is safer for users that have things configured already.
Change-Id: I6c45c70fbcdcdb8597310372fa331d764b1dd859
Reviewed-on: https://gerrit.instructure.com/158944
Reviewed-by: Omar Khan <okhan@instructure.com>
Product-Review: Steve Kacsmark <skacsmark@instructure.com>
QA-Review: Steve Kacsmark <skacsmark@instructure.com>
Tested-by: Jenkins
This should pick up coverage from both karma and jest
in Canvas proper. It should also pick up coverage from anything under
packages/*
closes CORE-1265
Test Plan:
- Run `COVERAGE=true yarn test`
- Coverage reports (coverage-final.json) should generate in all
packages such as (canvas-planner) as well as in coverage-karma
and coverage-jest
- Run `yarn run test:coverage`
- coverage-js folder should be generated. Opening index.html
should show the full coverage report
- Remove coverage-{js, karma, jest} and
packages/canvas-planner/coverage as well as .nyc_output to get back
to a clean state
- Run `RUN_TESTS_FIRST=true yarn run test:coverage`
- All tests should run and generate the appropriate report just
like the last time in coverage-js
Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066
Reviewed-on: https://gerrit.instructure.com/146098
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Test plan:
- `./script/docker_dev_setup.sh` still works
Change-Id: Id2021e3870cbd3d8645ecadff3034f3f2b0cfe08
Reviewed-on: https://gerrit.instructure.com/155306
Tested-by: Jenkins
Reviewed-by: Michael Hargiss <mhargiss@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Dariusz Dzien <ddzien@instructure.com>
Fixes PLAT-3550
Test Plan:
- Verify there is no 'API Token Scopes' under OAuth2
- Verify there is only one link 'API Token Scopes' under Resources
- Verify there is no code left related to generating the 'API Token
Scopes' table under OAuth2
Change-Id: Ib00a4aeec102eafc22169ac5322b581fef797a0b
Reviewed-on: https://gerrit.instructure.com/155247
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
The migrations now fail with `BrandableCSS::DefaultMD5NotUpToDateError`
if you try to run them before building assets. This commit updates the
docker_dev_setup.sh script to build assets first to avoid this error.
Also updates the script to use the correct docker package: `docker` in
the Ubuntu package repos is actually some kind of system tray thing. We
want the `docker.io` package:
https://packages.ubuntu.com/xenial/docker.io
Refs gh-1300
Change-Id: Iba9a6f9bffe1a9e60bd715f1214caaab0394d37e
Reviewed-on: https://gerrit.instructure.com/150865
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
Product-Review: Omar Khan <okhan@instructure.com>
QA-Review: Omar Khan <okhan@instructure.com>
closes: CORE-1497 (along with the other that has already been merged)
I missed this with the rest of my yarn workspaces commit. Don’t need it
anymore
Change-Id: I1608b8056699a563a81b3b97e7c54ae7ebbc7c09
Reviewed-on: https://gerrit.instructure.com/152453
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Run `script/nuke_node.sh` to clean everything up
Run `yarn install` it should install everything for everything
Run `yarn build` and `yarn test` they should work exactly as before
Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146
Reviewed-on: https://gerrit.instructure.com/151356
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Closes PLAT-3394
Test Plan:
- Run the `doc:api` rake task
- Navigate to /doc/api/index.html and verify there
are two new links in the OAuth2 section ("Developer
Keys" and "API Token Scopes")
- Verify both links work
- Verify the token scopes documentation has a table
for each scope group and includes all Canvas
scopes
- Verify "Resources" documentation pages now display
the scope along with each API endpoint
Change-Id: I2fea0ff531744dbaf63d24619b3c0e9655a25a7a
Reviewed-on: https://gerrit.instructure.com/151010
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Tested-by: Jenkins
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Test plan:
Run ‘yarn’
You should see output like:
Clearning cache for packages/canvas-rce
And not
usage: dirname path
Change-Id: Ida820eebf6811959e831b525ee8c0293df0c910b
Reviewed-on: https://gerrit.instructure.com/148780
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
refs ADMIN-761
When we added canvas-planner to the packages
directory, we set up a prebuild script to
build everything we needed for Canvas that
would run during yarn install. This causes
canvas-planner to have to do a lot that it
doesn't need to do when we just want the npm
packages to be installed (for the sync-
translations build or for other purposes)
so we're setting a specific build step
instead
Test Plan
- Specs pass
Change-Id: I72a0dc52cd9be1255985d69921d9910ba12e9ffe
Reviewed-on: https://gerrit.instructure.com/147565
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Mysti Sadler <mysti@instructure.com>
QA-Review: Mysti Sadler <mysti@instructure.com>
Update: Copyright years now reflect the year that the file was first
committed.
Refs: PLAT-3200
Test Plan: jenkins is still happy and specs pass!!
Change-Id: Ic26463defe41fc52cf4da8020976394c641f51d5
Reviewed-on: https://gerrit.instructure.com/143545
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Stewie aka Nicholas Stewart <nstewart@instructure.com>
Wwhen files change in canvas and under packages/canvas-planner, eslint
bombs out.
When files hange in package/canvas-planner alone, they aren't linted
using planner's rules
fixes ADMIN-830
test plan:
this isn't going to be easy. While including the changes here:
- commit a change to a canvas-lms .js file with an eslint error
> expect gergich to log it in the jenkins output in gerrit
- commit a change to a canvas-lms/packages/canvas-planner .js file with
an eslint error
> expect gergich to log both the above file eslint errors
- revert the change to the canva-lms file so only planner has a lint
errror
> expect gergich to log it
Change-Id: I337ee0ff3025875a8faf427e2fb749d76ae09bed
Reviewed-on: https://gerrit.instructure.com/142470
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Ed Schiebel <eschiebel@instructure.com>
- update README with new instructions
- update how canvas runs sub-package tests
- remove planner's test server
closes ADMIN-742
test plan:
- when jenkins runs, check to see that planner's tests run too
Change-Id: I2493b65f580c76b28f225f1330e99e1ceb1378b4
Reviewed-on: https://gerrit.instructure.com/139882
Tested-by: Jenkins
Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com>
QA-Review: Jon Willesen <jonw+gerrit@instructure.com>
Product-Review: Ed Schiebel <eschiebel@instructure.com>
closes: CORE-949
this also upgrades us to use what was on canvas-planner master
as of 1pm on 2/1/2018 (specifically 9569cc1)
test plan:
* canvas planner should work
* all automated builds should pass
Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2
Reviewed-on: https://gerrit.instructure.com/135947
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CORE-674
test plan:
* while running yarn 0.27, try to run `yarn`
* it should give you an error about how you need to upgrade yarn
* brew install yarn (or upgrade to yarn 1.3.2 however else you do that)
* run `yarn`
* it should work and should not make any changes to your yarn.lock or
node_modules
Change-Id: I916febab60755c93d3f2591c9067c1c8d8903674
Reviewed-on: https://gerrit.instructure.com/133501
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Jon Willesen