also: reduced need for specialized babel config
test plan:
- existing tests pass
flag=none
Change-Id: I2625830f01b2d65da0dad02e740f458dfb96863a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/323643
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
Build-Review: Isaac Moore <isaac.moore@instructure.com>
closes AE-283
this eliminates script/sync_lockfiles.rb and integrates its
functionality directly into `bundle install`, `bundle check`, etc.
it also generalizes a few pieces so that the same approach is used
for all use cases:
* syncing versions between the main Gemfile and gems in gems/
* maintaining separate lockfiles for no plugins/including
private plugins
* maintaining separate lockfiles for multiple Rails versions
(crossed with the previous bullet)
The differences between them are just small variations on how strict
versions must match between lockfiles, and requiring pinning of
versions not in the default lockfile.
For full details, checks the docs on BundlerLockfileExtensions
This does change the strategy for filtering private plugin dependencies
out of the committed lockfile(s) - instead of filtering based on hash
of source, simply don't even include private plugin gems in the gemfile
when building the filtered lockfile (i.e. dynamic Gemfile, rather than
monkeypatching bundler to filter out -- semi-succesfully -- private
plugins from the Definition).
It also changes the "default" lockfile for Canvas that gets checked
in to be Gemfile.lock, so that other tools that are not
multi-lockfile aware can find it (such as rubocop, dependabot, and
others). This will be the lockfile corresponding to the current
default rails version for Canvas, and without private plugins.
Change-Id: I7ba398381974acbc4445f34fa3b788e8a07c5ce6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/317888
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Build-Review: Cody Cutrer <cody@instructure.com>
refs FOO-2801
flag = none
[change-merged][build-registry-path=jenkins/canvas-lms/foo-2801]
[pin-commit-analytics=4fd9e2fbb7fc2790ba7985bb4025e901bf33a9e3]
this part reaches the goal of this series where we turn the locale
files that are used by our JS engine into plain JSON files that don't
need any special processing and are also of a simpler structure
before, translations were stored in a tree structure that we needed to
traverse in order to look up a translation, which we did by
deconstructing keys through the "." operator:
I18n.lookup("foo.bar.baz")
{
en: {
foo: {
bar: {
baz: "Hello!" // <-- this
}
}
}
}
now, translations are stored in a flat dictionary structure where the
keys are not processed in any special way but are instead "fully
qualified":
I18n.lookup("foo.bar.baz")
{
en: {
"foo.bar.baz": "Hello!"
}
}
this is nice when you consider that the previous structure contained a
mixture of nested keys and flat ones, based on different conditions:
{
en: {
"asdf_1234": "ASDF", // inferred, so it was never "nested"
"foo": {
"bar": {
"baz": {
"one": "One banana",
"other": "Many many bananas"
}
}
}
}
}
because, for example, keys that are inferred by i18nliner end up at
the root level and not nested. You also never knew whether a key was a
container or a phrase that was pluralized, because they both had the
shape of an object.
Now these distinctions are gone; a key is always fully-qualified
regardless of how it was specified:
1) inferred: I18n.t("Inferred key")
// => inferred_key_c49e3743
2) absolute: I18n.t('#buttons.cancel')
// => buttons.cancel
3) relative: I18n = useScope('outer')
I18n.t('something', 'Something')
// => outer.something
4) nested: I18n = useScope('outer');
I18n.t('something.inside', 'Something inside')
// => outer.something.inside
5) pluralized: I18n.t({
one: 'One banana',
other: 'Many bananas'
})
// => many_many_bananas_ce8e7fb7.one
// => many_many_bananas_ce8e7fb7.other
Change-Id: I7c33fbd2321d7d56994223d65f2572db0ac12ed5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293675
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@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>
Add linter to check if Dockerfile or Dockerfile.jenkins* changes
are found, Dockerfile.template is also included.
closes: DE-203
flag = none
Test Plan:
- Normal build passes with no linter errors
- Build with Dockerfile changes errors for no template changes
- Build with Dockerfile.jenkins changes errors for no template changes
- Build with both Dockerfile and Dockerfile.jenkins changes
errors for no template changes
- Dockerfile and Dockerfile.jenkins changes with changes
to Dockerfile.template for the jenkins changes only errors
for Dockerfile not modifying the template
Change-Id: I8545382c6e00c0c9bdce34d190bb6baed965d6c9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/254036
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
QA-Review: James Butters <jbutters@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>
Test Plan:
- Translations get built and put into
packages/translations/lib/
closes COREFE-258
flag = none
Change-Id: I05889f9c122aaf1263a6803daad8abd977b32e44
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/213813
Tested-by: Jenkins
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
QA-Review: Steve Shepherd <sshepherd@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
This moves eslint, stylelint, and xsslint to be part of our
JS build pipeline. It does not account for other linters that
are more general like tatl_tael linters and commit messages or
non-frontend language specific linters like rubocop.
Test Plan:
- The linters-and-js build on New Jenkins should run and actually
run the linters specified above.
closes COREFE-220
flag = none
Change-Id: I8f633caf9af025c83bbe68fbd1536276a838c159
Reviewed-on: https://gerrit.instructure.com/206106
Tested-by: Jenkins
Reviewed-by: Ed Schiebel <eschiebel@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@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>
A docker ignore entry was recently added for:
public/javascripts/translations/
This is a mirror of the .gitignore entry, however, there is one file
checked into the git repo that shouldn't be ignored, and is necessary
for docker image builds. This adds that file back.
Test Plan:
1. Docker image successfully builds from running:
docker-compose build web
Change-Id: Ia83fb6673197cb5cb8f98d9c230d65342b6be37c
Reviewed-on: https://gerrit.instructure.com/97721
Reviewed-by: Ryan Norton <rnorton@instructure.com>
Tested-by: Jenkins
Product-Review: Bryan Petty <bpetty@instructure.com>
QA-Review: Bryan Petty <bpetty@instructure.com>
Adds more missing entries to .dockerignore for compiled assets.
Test Plan:
1. Verify successful docker image build from new checkout.
Change-Id: I88b1a1260fb3eb47c8f6961fe23d2667af588a07
Reviewed-on: https://gerrit.instructure.com/97463
Reviewed-by: Jeff Belser <jbelser@instructure.com>
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
Product-Review: Bryan Petty <bpetty@instructure.com>
QA-Review: Bryan Petty <bpetty@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>
Adds a docker-compose.yml file, some containers for dependencies, and
some docker-compose-friendly config files. See
doc/development_with_docker.md for instructions on how to use.
Change-Id: I5eaee8a3e3c84bb608282bfd44ec7d49a123ef5f
Reviewed-on: https://gerrit.instructure.com/45508
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Addison Higham <ahigham@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins
Product-Review: Zach Wily <zach@instructure.com>
QA-Review: Zach Wily <zach@instructure.com>
Jacob Burroughs