fixes FOO-1824
flag = none
[pin-commit-analytics=7f2f049830a11e43f4a5d0031e3c4ecc3145ccdb]
[pin-commit-instructure_misc_plugin=9b505159130c0724ce6bcbb75d07d40ff16a1961]
read directly from gems/plugins/* instead of symlinks
- dropped dead brandable_css config property "all_sass_files"
- webpack test runner now generates a file that runs all plugin spec
files (from spec_canvas/coffeescripts)
test plan: you can remove your symlinks and still survive!
Change-Id: I0206c2d827aa9f59b0374b21f0863443dff3be0f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262346
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
flag = none
closes: DE-529
Test Plan:
Test All On Linux and Mac
-docker_dev_setup without mutagen
-test with dinghy not created, down, missing
-docker_dev_setup with mutagen
-with docker desktop not running
-with and without dory
-docker_dev_update with and without mutagen
-with update-code option and without
-update_canvas for local is not broken
-following Next Steps, all works for mutagen
Change-Id: I7690dc2d919cf1b9d8af86200ec8439da9135d16
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262293
QA-Review: James Butters <jbutters@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
This reverts commit 8704d83a37.
Reason for revert: Vault is not ready for prime time
Change-Id: I37c41be5345aa2ee362df4e7831cf64d2729668d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/261952
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Evan Battaglia <ebattaglia@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Test plan:
- From a rails console, run:
MicrosoftSync::GraphService.new('ourtenant').list_education_classes
- There should be an error telling you where to put the creds
- Follow the instructions, hopefully they are self-explanatory.
- Run again and and the education classes should be listed
Change-Id: I4a8cf6f788178345bac375b8be6aa31b04bc4a24
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262423
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Single dynamo table for all release notes data. Should support active-record
style patterns (mostly) for CRUD operations, plus querying the latest N visible
records by role and environment. Also supports paginated listing of *all* notes
for administrative purposes
fixes FOO-1752
Change-Id: Ic1e7e204e93e263479a738af18daf312c801269c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/261548
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
refs DE-496
flag = none
The pattern dir/ excludes a directory named dir and (implicitly)
everything under it. With dir/, Git will never look at anything
under dir, and thus will never apply any of the “un-exclude”
patterns to anything under dir.
The pattern dir/* says nothing about dir itself; it just excludes
everything under dir. With dir/*, Git will process the direct
contents of dir, giving other patterns a chance to “un-exclude”
some bit of the content (!dir/sub/).
Test plan:
• Adding a new file under /gems/plugins/account_reports/
gets picked up by Git version control as an unstaged change
Change-Id: I5e2e04426f224032301594237a67887e005b1285
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/259440
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
create rebase_canvas_and_plugin script to improve how we handle
rebasing code, and extract to a standalone script.
closes: DE-496
flag = none
Test Plan:
-Jenskins passes
-Run script, no options, no uncommitted changes, no merge conflicts
-script rebases canvas and all git plugins
-Run script with skip-canvas
-script does not rebase or stash canvas
-successfully rebases all git plugins
-Run script with skip-plugins
-script rebases canvas
-no plugins get rebased or stashed
-Run script with 'skip-plugins <name-of-plugin>'
-script rebases canvas
-script will rebase git plugins except for the one listed
-Run script with uncommitted changes to one or more repos
-script will prompt to stash changes and list the repos needing stash
-Allow script to stash
-script will stash then rebase those repos
-Do not allow script to stash
-script will exit with message saying to stash then re-run script
-Run script with merge conflicts with master on any repo
-script will fail to rebase that repo, but continue to rebase all other
repos.
-Ending message will inform of failed rebase and which repo
Change-Id: Id6a6efafc38f6363e853ccda1264d39cc070cf52
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/258351
Reviewed-by: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Andrea Cirulli <andrea.cirulli@instructure.com>
fixes FOO-1409
flag = none
no more client_apps, canvas_quizzes now lives as part of canvas-lms
proper inside app/jsx/, which makes the build leaner and leaves us with
one less thing to reason about
logical changes:
- converted from AMD to ES modules
- upgraded to recent react + react-router
- dropped RSVP in favor of native Promises
- used CanvasModal instead of home-grown Dialog
- removed dead code; notifications in particular were fishy as there had
no dependents at all and did not even show up in the graph
- ported tests to Jest, added more unit ones and two integration ones
- removed "config.onError" and now throws errors where appropriate
- disabled console statements in non-dev
:: test plan ::
- create a (old-school) quiz containing all types of questions
- as 3 distinct students, take the quiz and try to randomize your
answers
at this point it's helpful to have a reference to compare the screens; I
replicated the quiz on my production sandbox for this
- go to /courses/:id/quizzes/:id/submissions/:id/log
- verify it looks OK
- click on a specific question in the stream and verify the question
inspector widget works OK
- go back to stream and push "View table"
- verify the table and its controls are OK
- go to /courses/:id/quizzes/:id/statistics
- verify it looks OK
- click on ? in the discrimination index chart and verify it displays
a dialog with help content
- click on "X respondents" in one of the charts and verify it displays
a dialog with the respondent names
- verify the interactive charts do interact as expected (no logic
changed here so just a quick glance)
- link to "View in SpeedGrader" for essay-like questions works
Change-Id: I79af5ff4f1479503b5e2528b613255dde5bc45d3
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/256118
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
This story contains work to move Canvas Inbox and Storybook to `app/jsx` inside our Monolith. Storybook should now be enabled for all of `app/jsx` and works with our existing I18n code after updating webpack to load translations correctly.
Test Plan
1. Install node modules with `yarn`
2. At Canvas-LMS root, run `yarn storybook`
3. Storybook should open, test that Canvas Inbox components work as expected
Change-Id: Iccd2b103164a2da4e37b5746f4d9d2b5faf5f29d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/253024
QA-Review: Davis Hyer <dhyer@instructure.com>
Product-Review: Davis Hyer <dhyer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Davis Hyer <dhyer@instructure.com>
refs DE-324
Some tests require lib/api_scope_mapper.rb to be generated by the doc:api task, and this is a slow operation that all builds run before starting tests. Generated changes to this file are relatively rare, so let’s require developers to commit their changes to it to save time on all builds. In addition, install a linter to verify that matching changes are pushed.
[change-merged]
[build-registry-path=jenkins/canvas-lms/evaluate-webpack-docs]
Change-Id: Iaa6ebb1ba8cbb008191f6bee14b3bf2f413168e7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/250801
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Ryan Norton <rnorton@instructure.com>
Using the parallel_tests gem allows us to parallelize more
and a bit simpler. Removes headless stuff now that we don't
use it anymore, comments out video recording code since it
doesn't work, removes all knapsack code.
flag = none
Test Plan:
Jenkins rspec and selenium builds pass
rspec and selenium builds copy results to html publisher
rspec and selenium have nodes split into processes
Change-Id: Ibd00eba77f8193be5eadd41aef1e0617c9ae470c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/227677
Reviewed-by: Jacob Powell <spowell@instructure.com>
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
This will fix some issues with jenkins builds failing if the
patchset is behind some newer graphql changes, as well as allowing
us to include content defined in our plugins in the graphql.schema
file.
Test Plan:
- Jenkins passes
fixes USERS-210
flag = none
Change-Id: Ic44849ee57955e0b90395661a66f6d5840a38e87
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/222029
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Steve Shepherd <sshepherd@instructure.com>
Product-Review: Landon Gilbert-Bland <lbland@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>
Change-Id: I9a2da0fe619170e6a297ad5d1b9dd3e11daf3782
Reviewed-on: https://gerrit.instructure.com/206054
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
fixes COMMS-2290
flag Assignments 2
Test Plan:
- create a media upload assignment
- in a2 as a sutdent go submit an assignment
- notice a video upload button
- click button
- notice the modal is shown and you can drag and drop video files
or record yourself
- close modal
- notice no console errors or crashes
Change-Id: I9a6184efb99aa05d0d634d2744cca00abf5ae26e
Reviewed-on: https://gerrit.instructure.com/204375
Tested-by: Jenkins
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
closes: CORE-2904 CORE-2905 CORE-2906
This will send the XHR requests for the dashcards and for all the stuff
in the planner dashboard sooner. As in, as soon as the html document
comes back from the server, instead of waiting until all the js bundles
have downloaded and executed. This should remove a round-trip from
the dashboard page and you should notice the planner and dashcard
dashboards complete loading a lot faster. By sending the requests
sooner, our app servers can work on them while the browser is
downloading all the rest of the JS that it needs to run the page. And
by having our app servers work on that at the same time the browser
works on the JS, the entire page will complete loading faster.
Test plan:
* go to the planner dashboard
* you should see 4 requests with the type “fetch” in the network panel
in the waterfall right at the same time the html document is returned
* you should not see any more XHRs sent from axios on page load for the
planner dashboard (it should use the prefetched ones)
* in a prod environment, where you have multiple app server processes
handling requests, the planner dashboard should complete loading a lot
faster
* In that same prod like environment, go to the dashcard dashboard
* same thing, it should issue a “fetch” request right with the html
document comes back from the server and not issue an second
XHR once the JS is loaded.
* it should be complete loading significantly faster too.
Change-Id: I0503c1a4d913fd1baa4dad22b9a88333ff747c0d
Reviewed-on: https://gerrit.instructure.com/192161
Tested-by: Jenkins
QA-Review: Mysti Lilla <mysti@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
This gets canvas planner and canvas-rce on babel 7, which is a
prerequisite to canvas doing the same. Also, by not depending on the
Kitchen sink of ui-presets, it cleans a ton of unused stuff from our
node_modules/yarn.lock. It was originally 2 different commits but
in order to get the yarn.lock right, we have to do them all as one.
This also made it so we needed to have less “resolutions” in our
package.json since the newer versions of those things work fine with
the newer version of babel
So there are 2 test plan areas:
1. Canvas-planner
Closes: CORE-2575
Test plan:
* smoke test to make sure everything in canvas-planner still works/looks
like it used to in the canvas ui
* make sure the translation task (yarn check-transifex) still works
canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset
2. canvas-rce
Closes: CORE-2576
Test plan:
* smoke test the RCE editor
* theming should still work/look exactly as before
* make sure all the various build tasks (eg yarn test, test:coverage,
debug, lint, extract, etc) all still work as before
Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5
Reviewed-on: https://gerrit.instructure.com/183877
Tested-by: Jenkins
Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com>
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
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>
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>
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>
fixes PLAT-3311
test plan:
* run the rake task "doc:api"
* request the scopes from api/v1/accounts/:account_id/scopes
- you should get back a json object that includes the localized name
* request the scopes from api/v1/accounts/:account_id/scopes passing
the query param "group_by=resources_name"
- you should get back a json object with the scopes grouped by
localized resource_name
Change-Id: I2cab1822baef7cdda6471096153d60d4f7fe1e2b
Reviewed-on: https://gerrit.instructure.com/150233
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Test Plan:
- follow the instructions in spec/contracts/README.md to run
the live events contract tests locally
- follow the instructions in
spec/contracts/service_providers/canvas_lms/README.md to run
the "Generic Consumer" Canvas API contract tests locally
Change-Id: I316747f53731f411ab82432587596e335c2fd059
Reviewed-on: https://gerrit.instructure.com/149766
Reviewed-by: Tucker McKnight <tmcknight@instructure.com>
Tested-by: Jenkins
Product-Review: Michael Hargiss <mhargiss@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
this is to prevent canvas from copying everything in canvas-planner’s
node_modules dir into /node_modules/canvas-planner/node_modules
this will mimic the exact same behavior that pushing it to the npm
repository and pulling it from there in canvas’s package.json
test plan:
* do `ls node_modules/canvas-planner/node_modules/jest*`
* you should get: ls: node_modules/canvas-planner/\
node_modules/jest*: No such file or directory
Change-Id: Ie428b3d0a5d6cc1d9bec89ae00adb3d451dfc916
Reviewed-on: https://gerrit.instructure.com/139907
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: 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: 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>
just check in main.coffee, it pretty much never changes (especially since
the ember srgb will diaf soon)
this is (hopefully) one of the last pieces of the webpack puzzle
test plan:
* webpack and requirejs builds should be happy
* srgb should boot up in both
Change-Id: Icc1a6ad811cffca5ef18a6858d9103c9bbccf037
Reviewed-on: https://gerrit.instructure.com/103352
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Change-Id: I5879e3944d64eb67eb73e885174c83c808abc323
Reviewed-on: https://gerrit.instructure.com/103029
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes CNVS-34793
don't warn about it anymore, don't bother with a separate lockfile
(just make people suffer through installing rails via git), and
bump the rails branch a bit to pick up a deprecation warning fix
Change-Id: I430e5c97adf2f7db5a9badc2a13ba4d8b4161e5c
Reviewed-on: https://gerrit.instructure.com/101275
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@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>
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>
fixes SD-1724
in previous refactorings, plugin and ember js specs stopped running, and
regular specs started running twice
test plan:
1. confirm that ember specs run and pass now (110 of them)
2. confirm that more regular specs run than before (cuz plugins)
3. confirm that the regular specs don't run twice (unless it does the
retry thing)
4. `sudo -u clay test it every which way`
Change-Id: I24ac56b9d3082e25d15f06193c9a9e5c4313b7a7
Reviewed-on: https://gerrit.instructure.com/94305
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Change-Id: Id1900160375644ea33badaa9d9f9185fab6b81ac
Reviewed-on: https://gerrit.instructure.com/92726
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Cody Cutrer