closes: CNVS-36233
webpack adds a fingerprint to the filenames that it outputs, which
means that if the content changes, the filename changes. so over
time, unless you manually know to rm -rf public/dist/webpack*
periodically, you'll start accumulating a ton of javascript files
in that dir that you don't need which can slow down your editor's
grepping, take up a ton of space, and confuse you. this change makes
it so right before webpack emits all of the new bundles, it cleans up
the ones that were there. it only cleans up the ones in the dir it is
outputting to, so you can still have prod bundles in
public/dist/webpack-production/ and dev bundles in
public/dist/webpack-development
test plan:
* run webpack before you check this out
* check this out
* run yarn then run webpack again
* you should see something in the webpack output like:
WebpackCleanupPlugin: 220 file(s) deleted.
* and there should be only one copy of each bundle in the
public/dist/webpack-development dir.
Change-Id: Ide7a7f53c255c7aa5ad09fb4ff0bcfd7436b2852
Reviewed-on: https://gerrit.instructure.com/108147
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-35924
Test plan:
webpack && bin/rspec ./spec/selenium/interactions_report_student_spec.rb:33
Should pass.
Also, go to that page and verify that you
Can click on the column headers and sort by that
column
Change-Id: I68227ea44b44ee33ce2d1078299b2f62e52bd058
Reviewed-on: https://gerrit.instructure.com/106513
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes CNVS-28479
when a course has more than 200 students (so not all are prefetched) and
an adhoc assignment override specifies more than a page size (default
10) of students, it's possible for some students in the override to be
neither prefetched nor in the first page of results when fetched by ID.
make sure to fetch all pages of results when fetched by ID.
also make the 4 prefetch requests happen serially, and only once the user
begins interacting with the component (hover or focus). this way we don't
fetch more than we need to in small courses, and we don't fetch anything
if the teacher isn't using this part of the UI (generally the case). this
has the added benefit of speeding up selenium specs, as it has only one
server thread and the `get` waits for all ajax requests to complete
test-plan:
part 1:
- have a course with at least 201 students
- have an assignment in that course with an override that specifies 11
students
- have the 11th student specified for the override be the 201st student
in the course
- edit the assignment
- confirm you see the name for the 201st student (11th in override)
instead of "Loading..."
part 2:
- have a course with 51 students
- go to edit a new assignment
- confirm no /users ajax requests happen initially
- focus the "Assign to" widget so you can manage overrides
- confirm there are 2 ajax requests for /users
- confirm you see 7 students in the dropdown (either immediately or
with a very slight delay, depending on whether you clicked or
tabbed into the widget)
- confirm you can search for any of them without additional ajax
requests
Change-Id: I47ed202eb0d8ac1ad9e4ad21e50ceae930a6f3fe
Reviewed-on: https://gerrit.instructure.com/106693
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Leo Abner <rabner@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
test plan
* Specs should pass
* Load up gradebook and everything should work
Change-Id: I5734e9262244154c495725f89d92841547aba473
Reviewed-on: https://gerrit.instructure.com/106662
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
Product-Review: Shahbaz Javeed <sjaveed@instructure.com>
QA-Review: Shahbaz Javeed <sjaveed@instructure.com>
Fixes: CNVS-35540
test plan:
Since this upgrades the coffeescript compiler version,
it changes the format of the code that it generates so it has
the possibility to break things in a strange way if someone was
doing something in a way that was not actually supposed to be
supported as part of the coffeescript language spec or if we
run into a weird edge case of the compiler doing one thing before
but doing it in a way where our code breaks now. Having said that,
since there is no specific place where we intended things to change:
* automated specs should pass
Change-Id: I0630c25db7f97e69675992bba2ebccfdaf918ed3
Reviewed-on: https://gerrit.instructure.com/104677
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Test Plan:
- InstUI components in canvas should behave as before
Change-Id: Icf74b119347d1af7d037abe6bed1cab655ca4a48
Reviewed-on: https://gerrit.instructure.com/104670
Tested-by: Jenkins
Reviewed-by: Ed Schiebel <eschiebel@instructure.com>
QA-Review: Dan Sasaki
Product-Review: Colleen Palmer <colleen@instructure.com>
closes: CNVS-31785
test plan:
all builds should pass
Change-Id: I2925934692a3d2f115f1289d7b50cb72d8cb907f
Reviewed-on: https://gerrit.instructure.com/104492
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
fixes CNVS-34969
test plan:
- go /profile/settings and turn on high contrast
- go to the course people page (/courses/#/users)
- click on the +People button
> expected result: the modal honors high contrast
- enter some text in he text area
> expected result: nothing bad happens, as the event
handler for TextArea has changed.
- there's a TextArea in MessageStudents also, but I don't
know where to find it in the UI. You should probalby
test it doesn't blow up either.
Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743
Reviewed-on: https://gerrit.instructure.com/102133
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Dan Sasaki
Product-Review: Ryan Shaw <ryan@instructure.com>
Product-Review: Ed Schiebel <eschiebel@instructure.com>
fixes: CNVS-35414
the actual changes are here:
https://github.com/ryankshaw/brandable_css/commit/1fa1c2bc10c
Test plan:
Before checking this out, run:
rm -rf public/dist/brandable_css
RAILS_ENV=production node_modules/.bin/brandable_css
rm public/dist/brandable_css/brandable_css_*
cd public/dist/brandable_css/
git init .
git add .
git commit -am “original”
cd ../../..
Check this out, then run:
yarn install
RAILS_ENV=production node_modules/.bin/brandable_css
rm public/dist/brandable_css/brandable_css_*
cd public/dist/brandable_css
git diff
There should be no difference
to test the S3 stuff still works:
* set up your config/cavnas_cdn.yml file with a valid s3 bucket
* run `brandable_css`
* pull up a canvas page.
* the css should show up right and should be coming from your
cloudfront url
Change-Id: Iee1a7a916c3f17341adf513c2981b018420f7c16
Reviewed-on: https://gerrit.instructure.com/104016
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
this does make xsslint about 10x slower, since:
1. babel is slower than acorn
2. we now have to coffeescript everything on the fly
will revisit perf in another commit
Change-Id: I2ddad309d1921ba6a4e15cd79d3d8bd956a7e403
Reviewed-on: https://gerrit.instructure.com/103850
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Closes: CNVS-35152
This changes all our tooling that used `npm` to
Run scripts to use `yarn`. `npm` will still work
for now but if you have yarn installed, it will use
that.
Cheat Sheet:
old command -> new command
npm install -> yarn install (or just `yarn`)
npm run webpack -> yarn run webpack
npm test -> yarn test
See more at https://yarnpkg.com
Test plan:
* all Jenkins builds should pass
* without yarn installed:
* run script/nuke_node.sh
* it should work and warn you about how `npm` is deprecated
* now install yarn, e.g.: `brew install yarn`
* run script/nuke_node.sh again
* it should work and you should see silly yarn emoji
in the output and it should be a lot faster
* the docker changes I made should work and docker should
build correctly and use yarn.
Change-Id: I4aa31eeae3ecc504634a7c72a1ea0d3396f445e3
Reviewed-on: https://gerrit.instructure.com/102969
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Ryan Shaw