Closes: CORE-1143
Test plan:
* load canvas in prod mode in a non-English language. Click around
And make sure everything works
* in prod mode, do a test to compare load time to what’s on beta.
* page load time and js bundle size should be smaller
* click around in the quizzes client apps and the ember grade book
And make sure those things work
Change-Id: I93c28c4a6d22db95cd1c7e59cd3f5221d46fe1ed
Reviewed-on: https://gerrit.instructure.com/143422
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Reviewed-by: 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>
closes: CORE-1857 CORE-294
also closes: CORE-1856 CORE-294 CORE-1841 CORE-71 CORE-302 CORE-301
also closes: CORE-300 CORE-299 CNVS-34315 CORE-298 CORE-243 CORE-297
also closes: CORE-296 CORE-295
test plan:
now that the automated selenium & javascript specs pass for this the
last thing we need to do is to go manually click around and see if
anything breaks.
the best thing to do would be to open your browser console and look
for errors. deprecation warnings or propType errors or react warnings
are fine but if any actual errors get thrown that is something we want
to look into.
specific things to look at:
* account user/course search
* all the gradezilla/gradebook/grading stuff (specifically things that
have instUI <NumberInput>s)
* look at the submission cell editor
* the gb headers
* moderated grading
* the stuff for adding external apps
* theme editor
* new discussions/announcements
* the new permissions page
* the dasboard
* student planner
* dashcards
* global nav trays
* help menu
Change-Id: I0d71ffda08e306927616d3e976b09cd1775fba10
Reviewed-on: https://gerrit.instructure.com/163518
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This makes it so our sentry instance can be much more detailed
in the data that it collects
Change-Id: If44ea7bc54646988d681e6ad775951eb0e35436a
Reviewed-on: https://gerrit.instructure.com/154010
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
closes: CORE-865
In order to get accurate coverage reports (ie: so the coverage numbers
don’t only reflect a fraction of the total tests), when the COVERAGE
environment variable is set, it does not split them out into groups to
run concurrently. That way our linters-and-js-master build (which sets
that environment variable) will run the same as it always has and our
patch-set builds (which run the linters-and-js) will be faster.
Test plan:
* run ‘yarn test’
* it should be a lot faster than it used to be
* look at the linters-and-js build in jenkins for this commit
* it should have test reports for all both groups (coffee, js)
Of karma tests as well as for the jest tests.
* look at the coverage report after this gets merged. It should be
the same as it was before
Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518
Reviewed-on: https://gerrit.instructure.com/136373
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Refs: CNVS-38653
This upgrades us to webpack 3.5.4 and upgrades uglify
and Istanbul related stuff too:
Test plan:
* automated build should pass
* run yarn && COVERAGE=1 yarn test && open coverage-js/index.html
* it should run karma & open your browser to a bunch of istambul reports
* run `yarn run webpack-production`
* it should generate minified code that works in your browser when you
open canvas in prod mode
Change-Id: Id8b3c2457f47a30f299eafc6a8206102cfe98dc5
Reviewed-on: https://gerrit.instructure.com/122993
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
es6 modules that were added to tinymce plugins in public/javascripts
have been reverted to amd. even though webpack handles the es6
modules, it breaks esprima and istanbul. tinymce_plugins has been
un-excluded from the coverage
Change-Id: Ib5dee2415a5313c9e657b7fd2738afaa597753bf
Reviewed-on: https://gerrit.instructure.com/107698
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
TL;DR: running JS tests in canvas will be a lot faster & simpler
What you need to know as a developer writing JS in canvas:
Lets say you are working on the “dashboard_cards” feature, just run:
`npm run jspec-watch spec/javascripts/jsx/dashboard_card`
While you write code and it will have a watcher that catches
any changes and re-runs just the dashboar_card specs if you save any
file that went into it. It should run & reload in less than a few
seconds. You can give it the path to a specific spec file or have it
run an entire directory.
Or, if you are working on something that might touch a lot of stuff, run:
`npm run test-watch`
and while you are changing stuff, it will run *all* the QUnit specs on
any change. It should only take a couple seconds for webpack to process
the file change and to reload the specs in the browser.
Jenkins can now just run “npm test” for the webpack build. No need to
bundle install then run rake tasks just to run js tests.
This change also starts warning you when you have specs that take a
long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we
have some *really* slow js specs (like selenium-level slow) so if you
notice a slow spec that you our your team wrote, please fix it.
Longer details:
To test our JS in webpack, we used to
1. run webpack with an env var set so it only does our ember stuff
2. run karma against ember
3. run webpack again against all the rest of the specs canvas
4 run karma again against all the specs in canvas
that took a long time. this change makes it so both the ember
specs and the specs in the rest of canvas run all in the same karma.
it also makes it so karma runs webpack itself. so you don’t need
to run `npm run webpack-test && karma start` to run tests, just
`npm run test` (which is just an alias to `karma start`). it also means
there is now just one watcher (karma) instead of one for both webpack
and karma.
Closes: CNVS-34977
Test plan:
* Jenkins builds should pass
* Try running different variations of the commands up there in the
description. They should work and be fast-ish.
Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c
Reviewed-on: https://gerrit.instructure.com/102169
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: CNVS-34770
because the previous commit renamed
‘module’ to ‘qunit.module’ in all our specs,
we don’t need this loader anymore
in an effort to get rid of vendor code that is just
copy/pasted into our repo, this also has us use
npm to get qunit, sinon, and AXE.
test plan:
* because this only touches stuff for specs,
if js specs pass in both webpack and requireJS,
this should be good.
Change-Id: I1d1cbf187211ad1d04d775fe4469913b3942d74a
Reviewed-on: https://gerrit.instructure.com/101101
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
this slows things down quite a bit so we’re going
to not run it on every patchset build and only
run it in a post-merge or nightly build
test plan:
* jenkins webpack build should be faster
Change-Id: I9a2b8da37ac3bc3c2e81ea9c225a51c9ea817435
Reviewed-on: https://gerrit.instructure.com/101706
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
this will speed it up a tiny bit
test plan:
* webpack js tests should pass
Change-Id: I90b90efa340bc6b5738022c2706ae5887de4aeb3
Reviewed-on: https://gerrit.instructure.com/100645
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
closes: CNVS-34769
this is the result of running this find & replace
(^\s+)(module)(\s[\"\']|\()
\1QUnit.module\3
s/module/qunit.module/ in spec/coffeescripts
and the result of running this find & replace
(^\s+)(module)(\s*\()
\1qunit.module\3
in canvas-lms/spec/javascripts/
test plan:
* automated js specs should pass in requireJS and webpack
Change-Id: I65188cce4bd5e6e5caa199dc108393a93f400a67
Reviewed-on: https://gerrit.instructure.com/101100
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-34126
this is so it is easier to debug things in the
browser dev tools for karma tests. Because with it,
it adds a ton of cruft to the files so you don’t
actually see what’s going on.
test plan:
* automated webpack tests should pass
* make a change to a js spec file locally that will cause an error,
* when you see the error in the console, it should show actual filenames
and line numbers instead of just all being from one webpack.specs.js file
Change-Id: Icbc95541c445041543b6645836e00feb73f16abd
Reviewed-on: https://gerrit.instructure.com/98606
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-31779 [webpack] bundle file size
test plan:
* using webpack, look at the network panel in
the chrome developer console.
* the total ammount of javascript loaded for any
given page should be much less than before this commit
and about on par with what requireJS loads for the same page.
* use chrome network panel to throttle to "Regular 3G"
* from both a clean cache and a primed cache:
* make sure that the total time to render the page
is about on par with requireJS
first change: load webpack chunks from CDN
fixes: CNVS-32261
test plan:
* run `npm run webpack-production`
* check your page, it should load js files and chunks
from the same hostname the page is served from.
* now set a host: in config/canvas_cdn.yml
(for testing locally, I just set it to http://127.0.0.1:3000,
* restart rails and reload the page, now the scripts and
chucks should come from that new hostname
second change:include fingerprints in webpack bundle and chunk filenames
closes: CNVS-28628
with this change we don't need to run `gulp rev`
after running webpack and we can load both the bundle
and chunk files safely from the cdn, since they will
have content-based fingerprints so we can tell
browsers to cache them forever. (we set those
http caching headers in lib/canvas/cdn/s3_uploader.rb:53)
test plan:
* for both dev and production
* run `npm run webpack` (or `npm run wepack-production`)
* with a cdn configured in canvas_cdn.yml, run:
RAILS_ENV=<dev or prod> bundle exec rake canvas:cdn:upload_to_s3
* check to make sure that the page loads the webpack js,
that there are no errors, and it all came from the cdn
third change: properly handle moment locale & timezone in webpack
test plan:
(see application_helper_spec.rb)
* set a non-default user timezone, context timezone
and locale
* dates should show up in your timezone and and
the date helper strings should be in your language
better handling of moment custom locales
closes: CNVS-33811
since we now have hatian and maori, we need to do this in
a way that is not just a one-off for maori
test plan:
* set your locale to maori
* in webpack & requireJS make sure dates show up right
Change-Id: I34dbff7d46a1047f9b459d5e1c0d141f435d42fb
Reviewed-on: https://gerrit.instructure.com/95737
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This patchset duplicates the gradebook view hierarchy so that we can
develop gradebook enhancements side by side with the current gradebook.
A feature flag has been created called "Gradezilla" (this name is for
internal purposes only and should never be used in production) that is
only allowed in development and defaults to on. With this feature flage
enabled a button now appears next to the "individual view" button in
gradebook to navigate to Gradezilla. The page also has a header of
"Gradezilla" as to further distinguish the page since they look
identical at the start of this project.
In the future, we'll replace Gradezilla with something else but while in
development we wanted an easy term to search for to know which part of
the gradebook we were in.
closes: CNVS-33684
Listed below are the paths for which a corresponding gradezilla file was
created. See the git diff for full details.
app/coffeescripts/bundles/gradebook.coffee
app/coffeescripts/gradebook/*.coffee
app/coffeescripts/views/gradebook/*.coffee
app/jsx/gradebook/*.jsx
app/stylesheets/bundles/gradebook.scss
app/stylesheets/pages/gradebook/*.scss
app/views/gradebooks/gradezilla.html.erb
app/views/jst/gradebook/*.handlebars
spec/coffeescripts/gradebook/*.coffee
spec/coffeescripts/jsx/gradebook/*.coffee
spec/javascripts/jsx/gradebook/*.jsx
spec/selenium/grades/gradebook/*.rb
spec/selenium/outcomes/outcome_gradebook_spec.rb
spec/selenium/helpers/gradebook_common.rb
spec/selenium/grades/page_objects/gradebook_page.rb
spec/selenium/grades/setup/gradebook_setup.rb
spec/views/gradebooks/gradebook.html.erb_spec.rb
Test plan:
- Ensure that the feature flag for Gradezilla is enabled
- On the Gradebook page, there is now a button to take you to
Gradezilla
- Once selected, Gradezilla should become your default Gradebook until
the "Gradebook" button is clicked.
- Everything in Gradezilla should appear just as it does in Gradebook.
- Having selected Gradezilla, disabled the feature flag
- Ensure that upon returning to /gradebook, that the current Gradebook
is selected
- If the feature is disabled, you should not see the Gradezilla button.
Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1
Reviewed-on: https://gerrit.instructure.com/98498
Tested-by: Jenkins
Reviewed-by: Keith T. Garner <kgarner@instructure.com>
Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com>
QA-Review: KC Naegle <knaegle@instructure.com>
Product-Review: Keith T. Garner <kgarner@instructure.com>
Spec helper files are very useful, but are not supported via absolute
path requires.
test plan:
* ensure tests pass all builds
Change-Id: Ibdbe6939d95c77cd5149ab874189011d0e3d4aab
Reviewed-on: https://gerrit.instructure.com/96930
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Jeremy Neander <jneander@instructure.com>
QA-Review: Jeremy Neander <jneander@instructure.com>
example usage: `npm run jspec spec/javascripts/jsx/files`
refs CNVS-33223
test plan:
- current webpack test build should work exactly the same
- `npm run jspec` should build + run all specs
- `npm run jspec path/to/stuff` should build + run only specified
specs
- should work with both directories and individual files
- `jspec-watch` should watch + build a path, but not run specs
Change-Id: I788dd38a6c69a4c36a1300fcecf43678bc7f5327
Reviewed-on: https://gerrit.instructure.com/94625
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
QA-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
since we're on node 6.6 now, we don't need
babel for anything we were using it for in our
frontend build/webpack code that runs on node.
(except for es6 import/export)
Change-Id: I41352fdc8adb06fe1585565f63d808d249f92864
Reviewed-on: https://gerrit.instructure.com/91573
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-27679
if you name your config files *.config.babel.js
webpack knows to run them through babel. this change
makes it so use es6 stuff in the webpack.config files
(including everything in /frontend_build)
test plan:
run webpack
it should work
Change-Id: I6ceda3386227c30e106339f744f18dc61bbab54b
Reviewed-on: https://gerrit.instructure.com/73241
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs SD-743
fixes CNVS-26721
This adds a qunit assertion helper that wraps the aXe library. Rules can
be ignored by passing an array of rules in the options argument to the
helper.
e.g.
`assertions.isAccessible $html, done, { ignores: 'aria-valid-attr-value'}`
Test plan:
Undo the changes that I made to the DashboardCard.jsx component.
You should get a warning about invalid aria attributes because the
aria-controls attribute is referring to an element that doesn't exist.
To fix this, I modified the component to hide/show the color picker so that
the aria attribute value is valid.
If you add the ignores option as described above, the test should pass
without my changes.
To verify the dashboard card color picker changes:
- Verify that you can click or use the ENTER key on a dashboard card
cog button to bring up the color picker
- Verify that you can select a color and apply it to the card.
- Verify that you can click outside the color picker to close it
- Verify that you can hit the ESC key to close the color picker
- When the color picker is closed, focus should return to the the cog
button trigger
- After selecting a color you should be able to open the color picker again
and select a different color
The color picker in the Calendar should be regression tested as well.
Change-Id: I5d5bfdaf39df1e0cb8776144771baeb1ed31ff2a
Reviewed-on: https://gerrit.instructure.com/70638
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Tested-by: Jenkins
closes CNVS-25714
TEST PLAN:
web pack should compile in like 60 seconds rather than 600
Change-Id: I74716d9cccfd0253693660c0b4ad4368e91b72e7
Reviewed-on: https://gerrit.instructure.com/68497
Tested-by: Jenkins
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-24966
change js specs to work with web pack.
update some dependency references, make some aliases
for external dependencies to get the right version,
and clean up a bunch of leaky state.
TEST PLAN:
js tests should pass in web pack _and_ requires
Change-Id: If37fbce93e7e67021d90bacb470ffc4f1b17402d
Reviewed-on: https://gerrit.instructure.com/66309
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@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>
Ryan Shaw