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>
Adds the dinghy tap before trying to install it.
Test Plan:
1. On a machine running OSX without dinghy installed, run the
docker_dev_setup script. Verify dinghy is set up without issue.
Change-Id: I0479323aefd21554fb3bc2a8f00ced727b497496
Reviewed-on: https://gerrit.instructure.com/132850
Reviewed-by: Omar Khan <okhan@instructure.com>
Tested-by: Jenkins
QA-Review: Omar Khan <okhan@instructure.com>
Product-Review: Omar Khan <okhan@instructure.com>
This script sets up a full docker development environment from scratch,
on mac and debian-based linux.
Test plan:
- On mac, run script/docker_dev_setup.sh
- Answer the prompts
- Check that the script completes successfully
- Run docker-compose up
- Open http://canvas.docker
- Repeat on ubuntu xenial
Change-Id: Ic1eb0bad791fcbfe3953691623f2fbfb40b9298b
Reviewed-on: https://gerrit.instructure.com/130857
Tested-by: Jenkins
Reviewed-by: Bryan Petty <bpetty@instructure.com>
Product-Review: Bryan Petty <bpetty@instructure.com>
QA-Review: Bryan Petty <bpetty@instructure.com>
at some point we started loading/caching the cassandra config before
forking, which made every worker share the same keyspaces, causing
various specs to fail during the initial run
test plan:
* the build should be more stable
Change-Id: I804178152c165d72f3665ce1103c8af4736a9aa6
Reviewed-on: https://gerrit.instructure.com/122252
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
closes: CNVS-36805
I’m working towards turning on babel for public/javascripts
And so instead of having to worry about selectively adding excludes
For things in public/javascripts/vendor that we haven’t modified,
I’m just moving things out of there.
This commit just relies on gulp rev to put these files in
public/dist/* instead of having the intermediate artifacts
hanging around in public/javascripts/vendor/* that then
get copied/revved to public/dist by gulp rev.
This also minifies any gulp-revved js in production
Test plan:
* Nothing should change
* run compile_assets
* the javascript for your timezone data should load
just fine like it did before
* the lato fontface observer should still be working
* go to the site in IE, there should not be any
Js errors (like “Promise is not defined”)
Change-Id: I10b2e3f102276ab0ef5f58cbc0d981f5aa800522
Reviewed-on: https://gerrit.instructure.com/111251
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-36896
…since we just added the ability for plugins
to have their own package.json/node_modules
Change-Id: I963822a0c849c3bdf67faec9e77df16397a88d34
Reviewed-on: https://gerrit.instructure.com/112309
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 CNVS-36896
test plan:
check this out
check out g/108509 in gems/plugins/analytics
run `yarn`
you should see it install graphael for analytics
Change-Id: Iee6a2d8bb2ee46d1cddc596b972d447f9bb3b1d6
Reviewed-on: https://gerrit.instructure.com/111765
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
test plan:
* create a new file "test.rb"
* add "AUTO_CORRECT_LINTERS=1" to your .env
* install the pre-commit hook:
echo "bin/lint" >> .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
* git add .
* git commit -m "this should fail"
* verify the commit fails
* add the auto-corrected test.rb
* try to commit again
* verify it commits successfully
Change-Id: I3d52d6b192ca3bd83266a3e58d594acc3c516782
Reviewed-on: https://gerrit.instructure.com/111088
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
* tatl_tael still works (see test commits)
Change-Id: I1854693bd665f4018d1f0475dc922ac360b8d8d8
Reviewed-on: https://gerrit.instructure.com/109783
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
better foundation for more complex linters
test plan:
- tatl_tael still works (see test commits)
Change-Id: Iff463b69e7acf873418842883dbcab38c83b798b
Reviewed-on: https://gerrit.instructure.com/109373
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 make it so revert commits can make it through
without needing truncation done on the original commit message
Test Plan:
- Amend this commit and make the commit message really long
- Run script/lint_commit_message
- It will output an error message about length
- Amend the commit again and put "Revert" at the beginning
of the subject line.
- Run the linter again
- It will not print out the error now
Change-Id: Id2b57e202a0bbd46dbc8de29d9bcc984c9c5fe99
Reviewed-on: https://gerrit.instructure.com/109316
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
ensure we pick up the other location style when queueing up reruns
and when deciding not to re-run changed files
test plan:
1. see examples that were rerun in selenium build on PS 2
2. see modified examples that were not rerun in rspec build on PS 2
Change-Id: I31e8f4b8cc0ef8a0cc6cb2d5e8b66d69d1e931c0
Reviewed-on: https://gerrit.instructure.com/109288
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
include the line number of the not-rerunnable spec for easier tracking in
janky
test plan:
see intentional failures and rerun behavior in patchset 2
Change-Id: I3c381f94c71dc082a83f0f025794dc135b0336b4
Reviewed-on: https://gerrit.instructure.com/107760
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
just use whatever canvas uses, so we get the new hotness. also stop using
old jasmine since it brings along coffeescript
also tweak gem_npm stuff so they can have legit devDependencies
Change-Id: I39e3c6b96903dbbc9c4c38a886431d9b6f292616
Reviewed-on: https://gerrit.instructure.com/106476
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
should speed up local testing a lot, and jenkins a little bit (mainly the
rerun phase right now). in a subsequent test repo commit we'll speed up
jenkins a lot, as we'll do a truncate right after we migrate, which means
the cost will be incurred in the post-merge build and not the patchset
build
* don't double truncate one of the shards
* don't randomize sequences unless an env var is set
* don't truncate unless it looks like we've never truncated
(there are Accounts)
* remove some unnecessary switchmanning in rspec-queue
[ci verbose]
test plan:
1. run a spec on a freshly created/migrated test db
1. confirm you see "truncating all tables"
2. confirm you do not see "randomizing db sequences"
2. run the spec again
1. confirm you do not see "truncating all tables"
2. confirm you do not see "randomizing db sequences"
3. run the spec again with RANDOMIZE_SEQUENCES=1
1. confirm you do not see "truncating all tables"
2. confirm you see "randomizing db sequences"
4. in jenkins land on the initial run
1. confirm you see "truncating all tables"
2. confirm you see "randomizing db sequences"
5. in jenkins land on a rerun
1. confirm you do not see "truncating all tables"
2. confirm you see "randomizing db sequences"
Change-Id: Id24026e70afaa35abef4d02249be2c9ba27f1f21
Reviewed-on: https://gerrit.instructure.com/106043
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-34602
This makes it so we can use Jest to start testing things
as well as moves us forward to where everything will
use es2015 module syntax.
Webpack can handle import/export syntax natively.
Part of this was done by an automatic conversion tool
by running:
npm install ryankshaw/amd-to-es6
amdtoes6 --dir app/jsx --out app/jsx
but some of it had to be converted by hand since that tool
doesn't handle some es6 stuff like:
`...`, `static` or `import x {y, z} from 'foo'`
Test plan:
* webpack & selenium builds should all pass
* click around a couple pages to make sure things work
Change-Id: Id1b2bd55b4b7f27238754ceee720a77beca1df2b
Reviewed-on: https://gerrit.instructure.com/100536
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
there seem to be file system access collisions, and they are more
pronounced in the docker build.
test plan: `docker-compose build --no-cache web` should work
Change-Id: Ieeb734745846458eee4e689c3e98c384fe3b1f94
Reviewed-on: https://gerrit.instructure.com/105054
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Omar Khan <okhan@instructure.com>
Product-Review: Simon Williams <simon@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>
do our own babylon parse and pass the ast into xsslint
test plan:
* use `import` in your jsx
* :cat_dance:
Change-Id: I6ea240e82143f44ea360240ada492e6cbbdaa853
Reviewed-on: https://gerrit.instructure.com/104107
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@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>
Add docs on how to update them
Update everytime we run doc:api
Change-Id: I3c7aa55d051fa5474e267897138ab01c3c7c3fb8
Reviewed-on: https://gerrit.instructure.com/102177
Reviewed-by: Jesse Poulos <jpoulos@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins
Product-Review: Brad Horrocks <bhorrocks@instructure.com>
dedicate more cores to background loading on the initial run ... sometimes
the workers are so fast they block on it
test plan:
see previous patchset w/ verbose output where `waiting time:` for all
workers was <= 1.3sec
Change-Id: I17188a0f5285ac7e8e3f03a0b954b760008246f6
Reviewed-on: https://gerrit.instructure.com/103115
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
reimplement it using formatters. notable changes:
1. the index page has separate sections for "Initial", "Rerun 1", etc.
2. you now get error pages for before(:all) failures
3. you now get error pages for non-selenium failures
4. you now get links to pages for failures prior to the current one
5. in addition to not capturing screenshots/videos on too-many-failures,
we now stop making error pages if there are too many, so that we don't
fill up the workspace on mass badness
test plan:
1. see build in repo-who-shall-not-be-named
Change-Id: I54f065f1515f2b639b3f90b471a19e434a17aece
Reviewed-on: https://gerrit.instructure.com/102002
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
fixes: CNVS-34796
emitting assets for each of these timezones adds a
non-trivial amount of time to the webpack build.
by making it so webpack doesn’t have to do anything
about them, it goes a lot faster since there is just
a lot less work to do.
this commit also uses npm to get `timezone` instead
of a git checkout
test plan:
in requireJS & webpack,
* load a few pages, make sure your timezone data loads
* automated specs should pass
Change-Id: Ice3b7b6d4c7ac53315d5cb238d4213afb9faddc5
Reviewed-on: https://gerrit.instructure.com/101116
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
* for specs w/ no description:
* ensure they all run
* ensure we can use stats for them
* ensure obsolete stuff falls out of .test_queue_stats
Change-Id: I576228f3adf88e4186d39f0a0bcf84b2b56aba8c
Reviewed-on: https://gerrit.instructure.com/100476
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins
deprecating the test repo, one piece at a time. still using a highly
forked test-queue
test plan:
1. jenkins should be happy
Change-Id: Ie5e5618150703c01e9d279959323e8b87b547552
Reviewed-on: https://gerrit.instructure.com/100344
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
test plan:
* should get a webpack comment on patchset 1
Change-Id: I3fcd5d22b2c9d1b1480958e0ea134e4fefaee714
Reviewed-on: https://gerrit.instructure.com/99354
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
closes CNVS-34242
This makes dr_diff have an option to avoid checking
lines surrounding changes. It also sets up eslint
to take advantage of this rule.
Test Plan:
- Automated Tests Pass
- Eslint only flags errors on changed lines
(when run through Gerrit/Jenkins/Gergich or
via script/eslint)
Change-Id: I900430f21c4c925e8fd87bd62e75b271fa84d08e
Reviewed-on: https://gerrit.instructure.com/99048
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
test plan:
* see test commit verifying linters still work
Change-Id: I406c218309e824618869c9b5f3841af8387bf836
Reviewed-on: https://gerrit.instructure.com/98329
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Reviewed-by: Shawn Meredith <shawn@instructure.com>
Product-Review: Shawn Meredith <shawn@instructure.com>
QA-Review: Shawn Meredith <shawn@instructure.com>
fixes SD-1938
test plan:
* see that gergich still successfully comments on
linter output on patchset 1
Change-Id: I3beecfab405e57ba0e8705821d6d297fe7423c3e
Reviewed-on: https://gerrit.instructure.com/98317
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
refs CNVS-33837
Test Plan:
- Run script/eslint
- It works
Change-Id: I4ab0b5746633a535c85ce79e171a781f07fe9433
Reviewed-on: https://gerrit.instructure.com/97466
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
fixes: CNVS-33769
the file we were building with core-js was
not including an array iterator polyfill
so if you were using this polyfill in IE 11
and did `Promise.all([1,2])` it would fail
saying ‘1,2 is not iterable!’
test plan:
in IE11,
load a page in canvas
open the developer tools and type:
Promise.all([1,2]).then(function(o,t){console.log(‘it worked’, o, t)})
it should log:
“it worked 1 2”
and not throw an error
Change-Id: I49a6cd439c151b7703d77a7400856f438937443d
Reviewed-on: https://gerrit.instructure.com/97219
Tested-by: Jenkins
Reviewed-by: John Corrigan <jcorrigan@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
refs: ENGSEC-1
Runs Brakeman security scanning on CI, reporting only on relevant
source changes, and only with Medium confidence for now.
Test Plan:
1. Brakeman runs on Jenkins aux builds.
2. Security warnings are only issued for changed files.
Change-Id: I5ce0d4ff47203a5df31ca30cdcb7e9b0cba32b0a
Reviewed-on: https://gerrit.instructure.com/96775
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@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: CNVS-30278
The product design team wants to standardize
on Lato across all Instructure products. See
JIRA for more information.
With this change, we no longer have to use
font-weight: 300 etc to make the right
weight of Helvetica show up. We can go back
to simply using bold and normal, etc.; so
those rules have been updated in this
commit.
Test plan:
to accurately test this you need to set up your
canvas to use a CDN. there is a dev CDN that ops
has set up for us. you put the settings in
config/canvas_cdn.yml. slack ryan if you need help
setting that up or need to know what the values
are to use.
you also need to edit your config/environments/development.rb
file so it look like this:
config.action_controller.perform_caching = true
ENV['USE_OPTIMIZED_JS'] = 'true'
and then when you make any changes you need to run:
bundle exec rake canvas:compile_assets
bundle exec rake canvas:cdn:upload_to_s3
touch tmp/restart.txt
for the changes to be seen
- This change applies only to new UI. Legacy
should be unchanged.
- Clear cache and cookies first.
- Go to Canvas. On the first page load only
you should see a slight shifting of the text
as Canvas loads the Lato font and falls
back on the Helvetica system font.
- From that point on, Lato should be
cached in the browser and load instantly
when you move between views:
http://screencast.com/t/hZhUZOhH
- Canvas should still work in all supported
languages and browsers.
Not yet converted:
- TinyMCE textarea fiekd
- Mobile login
Change-Id: I861e609c01824f60ac38d3fc15e5b960a06e44de
Reviewed-on: https://gerrit.instructure.com/85737
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Dan Sasaki
Product-Review: Kyle Follett <kfollett@instructure.com>
symlink into node_modules makes globby sad, so give it an explicit list
of files and directories
this is the workaround suggested in https://github.com/jenseng/globby-js/issues/2
Change-Id: Ic9fc04b1bedb4e28e38c5eea0a2f1b127e3b5e2f
Reviewed-on: https://gerrit.instructure.com/94371
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
* add an invalid hex code to a css file
ex: app/stylesheets/pages/_rubrics.scss
color: #YARRRRRRRR
* save the file
* `script/stylelint`
* verify you see an error for this hex code
Change-Id: Iee7a0bbdae032761a7e0f1c91f2d99d469c1cb3d
Reviewed-on: https://gerrit.instructure.com/93575
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
test plan:
* add an invalid hex code to a scss file
e.g. _variables.scss:
color: #YARRRRRRRR
* run stylelint with: `script/stylelint`
* verify the colored output only returns your introduced error
Change-Id: Ia4f2adef3635f34154d50d61249b952a380208bf
Reviewed-on: https://gerrit.instructure.com/92229
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
npm installing for some gem should not be affected
by npm installing for another gem. so by doing them concurrently,
we can speed up the build process.
test plan:
* run `npm install`
* it should be faster because the npm modules for
canvas_i18nliner and selenimum install at the same time
instead of one after the other
Change-Id: I73d18db0fd3473e929ac1abff25206a929ab3a45
Reviewed-on: https://gerrit.instructure.com/84599
Reviewed-by: John Corrigan <jcorrigan@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
test plan:
* verify rubocop still comments on canvas-lms errors
-- add "sleep 1" to a controller
-- `./script/rlint`
-- verify you see an error about sleeping
* verify rubocop still comments on plugin errors
-- add "sleep 1" to a plugin
-- run rlint on the plugin
`./script/rlint --plugin custom_reports`
-- verify you see an error about sleeping
Change-Id: Id0df56c3adfcb6b673a0400e9f714ae22b78242c
Reviewed-on: https://gerrit.instructure.com/90657
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
fixes: CNVS-31887
test plan:
* using both webpack and requireJS:
* in ie11, load a page in canvas
* open the IE developer console
* type: Promise.resolve().then(function(){console.log('it works')})
* it should log 'it works' to the console
Change-Id: Ib76c39a5397ca2f28280ca5c108605c63266b38b
Reviewed-on: https://gerrit.instructure.com/90270
Tested-by: Jenkins
Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-31621
every other browser supports these features.
this will just make it so we can count on things
like Promise, Object.assign, [].includes etc (see
FEATURES_TO_POLYFILL at the top of
script/make-ie11-shim.js for full list)
what do people think of this? what do you think of the
approach, I don't want to include a polyfill in the
common bundle and force every other browser to download
this stuff they aren't going to need. but I still want
it to be performant as possible for those using ie11
Is there anything else people think we should polyfill?
the one I thought of is window.fetch, what do others
think about that?
test plan:
* in ie11, load a page in canvas
* open the IE developer console
* type: Promise.resolve().then(function(){console.log('it works')})
* it should log 'it works' to the console
* (that already works in other browsers, but you can
check to make sure that it still does there too)
Change-Id: Ie9c99a59631a13535903174a5e575427dbfeac4f
Reviewed-on: https://gerrit.instructure.com/89626
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
test plan:
1. lint_commit_message should run and pass on this commit
2. it should lint a plugin commit if you set GERGICH_GIT_PATH and
GERRIT_REFSPEC and not blow up on linting failures
Change-Id: I7349eb0885038ac11660b95a7e528735048be2bc
Reviewed-on: https://gerrit.instructure.com/88104
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
refs: CNVS-29725
test plan:
* run `node script/xsslint.js`
* it should work
(this is ran by jenkins so reall if it passes, it is good)
Change-Id: Ib9b68e486c32c91e3c430cea095a628daf51db2b
Reviewed-on: https://gerrit.instructure.com/87181
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:
* test commit
Change-Id: I9e3da787a56467c886d1e70f107b3abb916c6d1e
Reviewed-on: https://gerrit.instructure.com/82842
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
Change-Id: I793ce5d14a3da5ff153fc60ad52f2d567bdc2137
Reviewed-on: https://gerrit.instructure.com/81017
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
test plan:
* test commit
Change-Id: Iba8695913f05876dc076e2bb7b1e6d0584ad0710
Reviewed-on: https://gerrit.instructure.com/80944
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
test plan:
* test commit
Change-Id: I834581ac16c7ccaee07e1c5e02aff74da1ad30c2
Reviewed-on: https://gerrit.instructure.com/80518
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
test plan
* test commit
Change-Id: I09e55588027cd609d00e5066c6de04f1c2018a25
Reviewed-on: https://gerrit.instructure.com/79692
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Generate LTI Variable Substitution Docs from the code
Uses YARD's plugin hooks to generate the markdown.
I couldn't find a good way to do this with YARDs builtin generation
stuff. So I hacked together. No pretty, but gets the job done.
You can update the generated markdown by running this
```
script/generate_lti_variable_subustition_markdown
```
Our yard templates, dont process markdown files like YARD is supposed
to.i Not sure why? 🤷
Fixes https://github.com/instructure/canvas-lms/issues/592
Change-Id: If0728d357dc745d81381e818ed62d087d76f0e66
Reviewed-on: https://gerrit.instructure.com/74312
Reviewed-by: Andrew Butterfield <abutterfield@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins
Product-Review: Brad Horrocks <bhorrocks@instructure.com>
test plan:
* specs
* see test commit
Change-Id: Ia8084890312b674cc30a60077e9b2643d769cd4b
Reviewed-on: https://gerrit.instructure.com/78425
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
- change a file w/ a path that matches:
/(app|lib|public)\/.*\.(coffee|js|jsx|html|erb|rb)$/
but not:
/(bower|mediaelement|shims|vendor)\//
- ./script/tatl_tael
- verify you see:
[error] => Your commit does not include specs. Please add some to
verify your changes.
Change-Id: I725daf72c14180bb29c440f9867244a43dc5169d
Reviewed-on: https://gerrit.instructure.com/77579
Tested-by: Jenkins
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
in spite of the only_report_errors list, this should be something everyone
can agree on
test plan:
* spec-only commits and commit messages should be linted whether or not the
commiter is in the only_report_errors list
Change-Id: I077173db60f9f537d14f66b7acd396823e10a395
Reviewed-on: https://gerrit.instructure.com/65830
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
1. set GERGICH_GIT_PATH to a valid plugin gem path
2. script/lint_commit_message should lint according to the plugin's HEAD,
not canvas-lms'
Change-Id: I0976c39ca8278d8241c37ed464b24fcdf7cd9e58
Reviewed-on: https://gerrit.instructure.com/71928
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test-plan:
* put an unnecessary hyphen there ^
* gergich should not complain
Change-Id: Id092e5e9430bd6d7cb95b3f583f3bd1a5b1e82b3
Reviewed-on: https://gerrit.instructure.com/65749
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
sorry, not sorry; it's better than cloak'n'daggering
Change-Id: I641167cb402a616601e9c95499bec474947f4c66
Reviewed-on: https://gerrit.instructure.com/65719
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
the # is not necessary, but now you won't get misleading linter messages
if you do one, e.g. refs #PROJ-123
test plan:
1. the linter should not complain about this commit message
Change-Id: I3eb9e5de093a5b8948c2892bd3ecdec8c3ea4add
Reviewed-on: https://gerrit.instructure.com/65225
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
now you can have a colon between refs and the ticket, e.g.
refs: FAKE-123
test plan:
1. this commit message should pass the linter (even though that's not a
real ticket)
Change-Id: I32776d59c3ee2d7935c20caba759e0bd0b2596e9
Reviewed-on: https://gerrit.instructure.com/65208
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Now with full js/jsx/coffee/hbs/scss goodness \o/
If your commit ONLY touches js/jsx/coffee/hbs/scss/views/controllers or
specific whitelisted things, and doesn't touch global-y bundles or
layouts, then your commit may** be selinimized. That means it will only
run the selenium specs that care about those files.
If you touch lib, or gems, or models, or any global-y stuff, all the specs
will still run.
Also add the ability to override what we selinimize against when testing
changes to selinimum.
**Note that actual selinimization depends on a post-merge build having
succeeded for the parent (or a near ancestor). If the post-merge build
failed, or your build starts before it finishes, or there are
unselinimizable changes between your commit and the nearest ancestor with
selinimum stats, then your commit will not be selinimized :'(
See 4a83f6b6 for the full story.
Test Plan:
* Specs should pass on this commit
* It should not be selinimized because we touch package.json
* See dependent test commits where selinimization happens
Change-Id: I62c78c316876aaff07514a0f460ff4d608dac494
Reviewed-on: https://gerrit.instructure.com/65082
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
ruby port of the useful pieces of bridge's bash linter
test plan:
1. run it on this commit
2. it should complain that there is no ticket :P
3. feed it a commit message via stdin, e.g.
`echo -e "yay\n\na commit"|script/lint_commit_message --stdin`
4. confirm it behaves sensibly
Change-Id: I6bdd6db53e178c4d5d7372aafba47b60c4b9f076
Reviewed-on: https://gerrit.instructure.com/65124
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
we no longer use `npm run compile-sass` to do css.
also, css must happen before handlebars.
besides, all the js, css, styleguide and docs stuff
is handled by rake canvas:compile_assets already.
and in a way that whatever can run concurrently,
will.
(although, admittedly, the syntax to pass arguments
to a rake task, e.g.: [0,0,1,0] is pretty lame)
Change-Id: I83c8ceb21b476456f47f3ec37d4ba6088ca68088
Reviewed-on: https://gerrit.instructure.com/57768
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
what this does:
* Changes the way we generate css so we are able to generate custom
css for people that use the theme editor.
* Sets everything up so we can push all of our static assets
(js, fonts, css, images, etc) to s3 pre-deploy and serve them
from cloudfront. Yay! faster canvas for everyone!
* as part of that, this enables the rails asset pipeline just so we
can use it to put md5s in our urls. we don't use it for any of the
coffeescript/sass/sprockets transformer stuff.
* adds a new "Theme editor" functionality (only for people that have
have the use-new-styles feature flag turned on) where an admin for
an account can pick their own colors/images for all the users
at their account/school.
* when the user is done saving things in theme editor, it will,
in a delayed job, generate all the css with against the variables
that user specified and push it to s3 so it will be available to
anyone else that requests it. (the delayed job will shell
out to a node.js executable called `brandable_css`).
* ability to pick an existing shared theme and to reset to
blank theme. closes: CNVS-19685
* gets rid of jammit.
test plan:
(this is exaustive, so not every person has to do every step
but we should make sure at least someone does each of these things.
maybe as part of the review add a comment if you have done one of these
bulletpoints)
* before you check this out, compile all css and copy the
public/stylsheets_compiled directory somewhere. after you check out
this code and regenerate all the css. make sure there are no
significant changes to the css output. (we updated the versions of
node-sass and autoprefixer that we use so we want to make sure they
don't change things in a way we weren't expecting)
* make sure the way we load css for handlebars templates still works.
eg: if there is a handlebars template at
app/views/jst/some/template.handlebars
if there is also a scss file at
app/stylesheets/jst/some/template.scss
then that stylesheet should get loaded when that template is rendered
* check out the code and run migrations. browse around canvas,
make sure css and js files load correctly as before.
* cody, jacob, or someone on queso: look at the db migrations and
make sure everything looks good and that I am handling sharding
correctly.
* verify that both rake canvas:compile_assets and guard, works as well
as `node_modules/.bin/brandable_css` (note: if you have
"node_modules/.bin" in your PATH (which you should), it will also
work with just `brandable_css`)
* verify that passing the --watch option to
`.bin/node_modules/brandable_css` works and picks up changes to
sass files, images, fonts, or any other resource that goes into
a css file. and that it only recompiles the css files that actually
depend on that file.
* go to https://github.com/ryankshaw/brandable_css and check out the
code there. that is what is actually doing the sass compiling
* create a config/canvas_cdn.yml file and add aws access creds and
an s3 bucket and cdn hostname (for testing, you can use the credentials
for instructure_uploads_engineering from
https://gollum.instructure.com/OtherServiceTestAccounts ). for a test
cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that
is a cloudfront bucket I set up on my personal account that points to
instructure_uploads_engineering
* run rake canvas:compile_assets again, this time, at the end, you
should see it run the assets:precompile task that puts md5s in filenames
and, gzipps them, and copys them to public/assets.
then you should see it run canvas:cdn:upload_to_s3
(look at log/development.log for progress),
which pushes everything to s3.
closes: CNVS-17333 CNVS-17430 CNVS-17337
* try out the theme editor: turn on new styles, go to accounts/x
(where x is the @domain root acount you are testing from) and click
the "theme editor" button on the right side of the page.
that should take you to a page that has the ability to pick colors/images
on the left side and preview your changes in an iframe on the right
closes: CNVS-19360 CNVS-20551
* test the "preview", "save", "reset", and "choose existing" functionality
closes: CNVS-17339 CNVS-17338 CNVS-19685
* make sure that the themeeditor works both if you have
config/canvas_cdn.yml set up and enabled as well as if you don't.
if it is enabled, you should see it push the css for just that new
brand config to s3 when you hit preview, and the css
should be accessible from the cdn you configured.
Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22
Reviewed-on: https://gerrit.instructure.com/53873
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
also start moving the more complicated logic
from the rlint script into tested helper
classes
Change-Id: I5c3916b0c7e695389b552dc1a6b4353aaaeba290
Reviewed-on: https://gerrit.instructure.com/52743
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
lets rlint only run with local changeset unless you specify "--heavy"
Also checks for whether you actually touched a line
or not before deciding an INFO comment is relevant
Change-Id: I4a960c72644dfc46aca7a51d04321711cef0850c
Reviewed-on: https://gerrit.instructure.com/51992
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Ethan Vizitei <evizitei@instructure.com>
on jenkins this was taking up to 9 minutes.
By removing the file I/O and batching
the georgich commits, this ran locally on my
sentry patch set in 15 seconds.
Change-Id: I23b0df9b9396829de4b8ff084f4f92df6e698da2
Reviewed-on: https://gerrit.instructure.com/51987
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Rex Fleischer