This reverts commit ce771d353b.
fixes CNVS-32874
test plan:
- make sure that old icons are working appropriately, especially with
inst-ui components
Change-Id: If749cec08302b1bd252c0938ad9fd2329e1c1040
Reviewed-on: https://gerrit.instructure.com/93540
Reviewed-by: Colleen Palmer <colleen@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
Tested-by: Jenkins
QA-Review: Pierce Arner <pierce@instructure.com>
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
fixes CNVS-32581, CNVS-32619, CNVS-32652
Test Plan:
- npm install should give version 0.16.0 of instructure-ui package
Change-Id: Iea942adf2da251ea06ad19844eee8df21b8fb95b
Reviewed-on: https://gerrit.instructure.com/92784
Reviewed-by: Stephen Jensen <sejensen@instructure.com>
Product-Review: Stephen Jensen <sejensen@instructure.com>
Tested-by: Jenkins
QA-Review: Pedro Fajardo <pfajardo@instructure.com>
closes: CNVS-29706
This initial commit introduces Instructure Icons into Canvas.
Due to the range in aesthetic impact of including both line
and solid icons, the change is expansive and will be refined
in subsequent commits. The purpose of this commit is to:
- Make InstIcons available in Canvas allowing the use of the
react components
- Replace the current icon font with the new InstIcons font
- Allow for use of both 'Line' and 'Solid' icon variants
- Update the styleguide to reference the InstIcons github
documentation for examples
- Remove font custom from Canvas
Test Plan:
- On compiling, icons in Canvas should now be changed to the
corresponding Instructure Icons as can be seen here
http://instructure.github.io/instructure-icons/
- The icon default displaying in Canvas should be solid icons.
If the variant "icon-Line" is added to an icon's css class,
it should display as line. For example, in the case of
<i class="icon-edit"></i>, adding
<i class="icon-edit icon-Line"></i> would result in a line
version of the edit icon displaying
- As a developer, you should be able to use InstUI react icons
- The rake task `bundle exec rake icons:compile` should no
longer exist
- The styleguide should no longer display example icons, but
should now include a link to the Instructure Icons github
documentation
Change-Id: Id5a2f7be33b8e5bed76867da067309d044b5be06
Reviewed-on: https://gerrit.instructure.com/91014
Tested-by: Jenkins
QA-Review: Pierce Arner <pierce@instructure.com>
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Product-Review: Jennifer Stern <jstern@instructure.com>
Product-Review: Kyle Follett <kfollett@instructure.com>
fixes CNVS-31803
test plan:
- take a quiz with several students
and get different scores
- go to the quiz statistics page
- with a screenreader go to the chart
showing the breakdown of scores
by percentile
- you get a description of the bars
in the screenreader (X students in
percentile Y)
Change-Id: I100577687058d27a9921773e81edc64b3cf1cb87
Reviewed-on: https://gerrit.instructure.com/90642
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
Tested-by: Jenkins
QA-Review: Robin Kuss <rkuss@instructure.com>
Product-Review: Nathan Rogowski <nathan@instructure.com>
fixes CNVS-31926
Also note: we no longer want to load all of InstUI at once, and instead
prefer to load components as we need them.
Test plan:
* automated tests pass
Change-Id: Ia3b73bd68c94901da64c432ab88f3b7a1634a77f
Reviewed-on: https://gerrit.instructure.com/90271
Reviewed-by: Michael Brewer-Davis <mbd@instructure.com>
Tested-by: Jenkins
Product-Review: Colleen Palmer <colleen@instructure.com>
QA-Review: Colleen Palmer <colleen@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>
When using webpack, we pack up everything outside of karma and
assuming you've set webpack to generate source maps it doesn't actually
use them. This makes it so that it does use them so output can
be much better.
Test Plan:
- Have your environment set up to use webpack
- Change webpack.test.config.babel.js:23 to be:
testWebpackConfig.devtool = 'inline-source-map';
- Comment out lines 64-68 of the same file
- Run npm run webpack-test-watch to bundle the
tests
- Run the specs (doc/testing_javascript.md)
- Make a test fail... you should see a mapping
from bundled test file to the actual file.
Change-Id: I650fe995d6aa595d89da5ae614d5407a699e75ec
Reviewed-on: https://gerrit.instructure.com/89822
Tested-by: Jenkins
Reviewed-by: Joel Hough <joel@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
closes: CNVS-29725
this gets everything working on node 6.
As far as our build process goes, it cannot support
running on both node 6 at the same time as 0.12
since our i18nliner handlebars stuff uses jsdom and
one version of it only works on node <4 and the
next only works on 4+.
But the stuff in the production dependencies in
package.json, aka the stuff that runs on the job
servers (brandable_css), can work on both. we just
need to run npm rebuild on the job servers if the stuff
that was npm installed into ./node_modules was compiled
against a different version of node. that is done here:
https://gerrit.instructure.com/81254
that commit needs to be committed to caturday before
we commit and deploy this to beta
as far as managing node, there are 2 "official"
ways that will make you life easier, you can either
just use docker or use nvm (https://github.com/creationix/nvm)
if you use nvm and if you use ZSH:
Put this into your $HOME/.zshrc to call nvm use automatically
whenever you enter a directory that contains an
.nvmrc file with a string telling nvm which node to use:
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc() {
if [[ -f .nvmrc && -r .nvmrc ]]; then
nvm use
elif [[ $(nvm version) != $(nvm version default) ]]; then
echo "Reverting to nvm default version"
nvm use default
fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc
but however you do it, as long as you have node 6.2
installed it should work
test plan:
* install nvm
* check this patchset out
* run bundle exec rake canvas:compile_assets
* it should work
* use theme editor to preview a change to a theme
* it should work
Change-Id: I1cc9faed361938afc713c4b921042386b956db70
Reviewed-on: https://gerrit.instructure.com/80839
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@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>
fixes: CNVS-30802
these are the npm deps I upgraded as part of my
node 6 commit that should work fine on both node
0.12 and node 6. I am making this change as a separate
commit so you can see exactly which ones only work
on node 6 (or 0.12, or vise-versa) by looking
at the package.json changes in the node 6 commit
test plan:
run npm install
it should work
Change-Id: I7fca4738ad3593caa7512ebb6be55866ea614af3
Reviewed-on: https://gerrit.instructure.com/87028
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ian Hoerner <ian@instructure.com>
fixes: CNVS-30799
This updates us to the latest inst-ui, which addresses conflicts
instructure-ui.js had with requirejs.
TODO: once the next version of instructure-ui is released,
we should be able to delete public/javascripts/instructure-ui.js
and rename the public/javascripts/InstUI.js sym link to
instructure-ui.js (and update .xssignore and canvas.rake accordingly)
Change-Id: I3fd9f4bac0447c37754f9f85165ad05728672c1f
Reviewed-on: https://gerrit.instructure.com/87050
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Neil Gupta <ngupta@instructure.com>
QA-Review: Neil Gupta <ngupta@instructure.com>
fixes: CNVS-30799
...since it is not just needed for our build
tooling, it is actually needed in the actual app
because common.scss @import ../../../node_modules/instructure-ui/dist/instructure-ui
directly. so without having this in the prod
dependencies, it will blow up when someone
tries to preview in the theme editor and at deploy
time when we run brand_configs
test plan:
run these terminal commands:
* rm -rf node_modules
* npm install --production
* node_modules/.bin/brandable_css
those should work.
now open theme editor
make a change
hit preview
it should work
Change-Id: I87e9896e668d16b653e868bd202a807c204f2f95
Reviewed-on: https://gerrit.instructure.com/87027
Reviewed-by: Neil Gupta <ngupta@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-30588 for reals this time
test plan:
npm install --production should work on node 0.12.x
(the "--production" part is important here, since
it worked before for devDependencies but we want
to specifically test if it works just installing
prod dependencies)
Change-Id: I27d90db87f3be2891a8e04eb413f1cd7f30dd52f
Reviewed-on: https://gerrit.instructure.com/86151
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-30588
test plan:
npm install should work on node 0.12.x
Change-Id: Ic77bc68c649e14faa7cf89d4378f2520c023374e
Reviewed-on: https://gerrit.instructure.com/86129
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This prevents our gulpfile from printing out an error trying to
require babel-register before falling back to babel-core/register.
This is now possible because we are on Babel 6.
closes gh-867
Test Plan:
- Run compile assets
- At the end during the 'rev' step, you should not see:
```
Failed to load external module babel-register
Requiring external module babel-core/register
```
- Instead you should just see:
```
Requiring external module babel-register
```
Change-Id: I3168dbdfb733979e762537f40fdb96effbefa328
Reviewed-on: https://gerrit.instructure.com/85571
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
closes CNVS-29019
closes gh-817
Test Plan:
- bundle exec rake canvas:compile_assets should compile
/app/jsx and /specs/javascripts/jsx properly
- Automated tests should pass
- Areas of Canvas that use JSX/ES6 should work properly such
as Moderated Grading, Files, and the new Admin search page
Change-Id: Ic2aefbe98dd65a9b38407a68dc569e19a9e300e2
Reviewed-on: https://gerrit.instructure.com/78232
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Fixes CNVS-30301
Test Plan:
- Running the js tests locally should generate
a folder called coverage-js with an index.html
file that has the coverage information
Change-Id: Ib57b40c60791324d0a1eafab4c541957a2c2e7e7
Reviewed-on: https://gerrit.instructure.com/84839
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins
Product-Review: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
this was a blocker for upgrading to node 6 since
karma 0.x has a strict node version requirement
of <=4, so it would not work on node 6 (although,
ironically, if you forced it it would still work)
closes: CNVS-30308
test plan:
* run `npm install && bundle exec rake js:test`
* it should work
* the jenkins builds should all work
Change-Id: Ifd9ae12347d7901cf2bafee110230699987b2511
Reviewed-on: https://gerrit.instructure.com/84590
Tested-by: Jenkins
Reviewed-by: Matthew Sessions <msessions@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-29785
the newest versions of node-sass do not allow
@import inside an @if
also, this:
@if something { $foo: 'bar'}
@else { $foo: 'baz'}
// on this line foo is not supposed to exist,
//but it erroneously did in old node-sass and we relied on it
this blocks us from upgrading to node 6 because the
gcc on the jenkins and job boxes is to old to compile
node-sass 3.4 from source against the v8 in node 6. but
there are prebuilt binaries it can use for node-sass
3.7+, so it doesn't need to compile from source
test plan
* check out this commit
* compile assets
* it should work
* the css it outputs should be exactly the same as before
Change-Id: I797ce68ecc82566401076771784c8be590233e27
Reviewed-on: https://gerrit.instructure.com/81513
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
a couple things:
* our spec matcher was matching spec files in some of our
bower components and so it tried running those
tests, which obviously failed
* removed some cruft leftover from the switch from
testem to karma a long time ago
Change-Id: I61dc400bbfae0a679c698a90c7bcddd4fcf9fecc
Reviewed-on: https://gerrit.instructure.com/77908
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-28888
by pinning node-sass to 3.4.2 in brandable_css
we avoid the bug introduced in 3.5.1 where
it won't allow us to @import inside an @if
test plan:
* run compile_assets
* css should look the same as before
Change-Id: I437afd60e4dde60e65d03de4deca5a67ef7e3897
Reviewed-on: https://gerrit.instructure.com/77639
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-27874
TEST PLAN:
1) run webpack build
2) should be fast
3) load the calendar page
4) all the styles should look good
Change-Id: I28d9205fbf53616ed9264d8393dc617962e43c22
Reviewed-on: https://gerrit.instructure.com/74197
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-27679
if you name your config files *.config.babel.js
webpack knows to run them through babel. this change
makes it so use es6 stuff in the webpack.config files
(including everything in /frontend_build)
test plan:
run webpack
it should work
Change-Id: I6ceda3386227c30e106339f744f18dc61bbab54b
Reviewed-on: https://gerrit.instructure.com/73241
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs CNVS-25916
Use an AMD-rewritten version of old react-router
and expose some of reacts internals that
react-router depends on (named AMD across files
is something web pack does not support), and leave
the other version for the require-js build for now.
Also, add gulp rev as a web pack post build action.
TEST PLAN:
1) regression check QLA and Quiz Stats
to make sure reworking their dependencies didn't
crash everything
Change-Id: Id2b448a334494ebd3d353678742bf07c1b7833eb
Reviewed-on: https://gerrit.instructure.com/69837
Tested-by: Jenkins
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
refs CNVS-25916
remove dynamic requirements for env configs,
use separate jsx loader for client apps,
update client app plugin to use old react version,
rewrite selenium spec to be an integration test
rather than executing arbitrary javascript,
and MAJORLY refactor loading patterns of client apps
to avoid sharing code with differences delineated
by opaque require re-writes.
Also moved some code that was in "common" client
app but only used by one actual client app down
into the app that uses it (simplifies dependency
tracing).
TEST PLAN:
1) make sure quiz statistics still works ok under
require js build, no behavior should have changed
2) also make sure quiz log auding works under require-js
Change-Id: I0e5ee3eda9da16e0ad48cf858761735c71df801c
Reviewed-on: https://gerrit.instructure.com/69804
Tested-by: Jenkins
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-25714
TEST PLAN:
web pack should compile in like 60 seconds rather than 600
Change-Id: I74716d9cccfd0253693660c0b4ad4368e91b72e7
Reviewed-on: https://gerrit.instructure.com/68497
Tested-by: Jenkins
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-24966
change js specs to work with web pack.
update some dependency references, make some aliases
for external dependencies to get the right version,
and clean up a bunch of leaky state.
TEST PLAN:
js tests should pass in web pack _and_ requires
Change-Id: If37fbce93e7e67021d90bacb470ffc4f1b17402d
Reviewed-on: https://gerrit.instructure.com/66309
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
this pins the acorn version, so we have less strict `undefined` handling
test plan:
n/a, xsslint should pass again
Change-Id: I70ac1de7ce303ac23c70242e13933dbd5ab0c9d0
Reviewed-on: https://gerrit.instructure.com/66760
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
closes CNVS-24124
makes working with web pack possible in canvas
instead of require-js. See doc/working_with_webpack.md
for instructions.
TEST PLAN:
Nothing should change in non-webpack'd behavior
Things should mostly work when you use the
USE_WEBPACK environment variable, but make sure to document
and ticket things that don't
Change-Id: I493a259a609e9e183950bc57aa5876df70108547
Reviewed-on: https://gerrit.instructure.com/64386
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
the actual changes are in:
https://github.com/ryankshaw/brandable_css/compare/8cff7...master
make sure to review that too
first thing it fixes:
better logic for knowing what to skip in brandable_css
closes: CNVS-24039
* gets rid of any manifest files on s3.
The only manifest file that is used is the one
on the local disk which only includes metadata
about the "stock" (unbranded) css files which
are generated as part of the tarball on the
deployer's vm.
* which means we no longer use the env var:
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST
* because the filenames on s3 include:
<css bundle name>
<combined checksum of stock version of this file>,
<md5 of this brand config>
if that css file exists, we know we don't need
to generate or upload that file again. and we
don't need a shared manifest on s3 to figure that
all out.
test plan:
* with a canvas_cdn.yml file configured
* run brandable_css
* run it again, it should be fast
* rm -rf public/dist/brandable_css
* run it again, it should generate all the "stock"
(unbranded) css and skip all the brand configs
* change a value in variables.scss
* run it again, everything should be recompiled
also fixes: CNVS-24269 and CNVS-23786
to test:
* with a canvas_cdn.yml enabled and delayed jobs running
* go to theme editor for your account
* change a value to a non-default value
* press preview
* it should generate the preview correctly
(you should not see the giant svg icons)
* "apply" it, it should still not have the unstyled
giant svg icons
Change-Id: I992c11b392a0d6bbb045b16a78036f5ec1afed31
Reviewed-on: https://gerrit.instructure.com/65203
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This replaces the deprecated JSX compiler formerly provided by
react-tools to use the Babel preprocessor.
This allows us to use ES6+ inside Canvas :)
Unfortunately, we had the jsx pragma hanging around all over the place
and Babel considers this an ERROR now... so I ripped them all out.
Babel also turns on strict mode for JS files, which means I needed
to fix a few things in other places to make it work such as duplicate
object keys and variables without declaration. DueDateTokenWrapper.jsx
had a problem with a 'this' being seen on the global level which Babel
detects to be nothing so it throws in an undefined. I reworked it so
that the function should still have the intended effect and 'this'
is properly scoped.
closes CNVS-24123
Test Plan
- Make sure all JSX compiles via Guard and via js:jsx rake task
- Make sure nothing is broken in any of the react-y areas of
Canvas.
Change-Id: I5ab8f7f435504f8269e2b7da96813337676cf175
Reviewed-on: https://gerrit.instructure.com/65451
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Tested-by: Jenkins
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@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>
fixes: CNVS-23783
also closes: CNVS-23841
all the real changes are here:
https://github.com/ryankshaw/brandable_css/compare/2cf4ad3...master
review those too while you are reviewing this.
(sidenote: I was going to get this all set up to host
that npm package all official from the instructure
github account but, apparently we are going to get
our own private npm so I didn't want to go through
all of that fuss just to change it again when that
gets figured out)
https://gerrit.instructure.com/64465 should be
submitted along with this
test plan:
* bundle exec rake RAILS_ENV=production \
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST=some_unique_key \
brand_configs:generate_and_upload_all
* it should generate all your css from scratch
* run that again, it should say "no sass changes"
* bundle exec rake RAILS_ENV=production \
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST=other_key \
brand_configs:generate_and_upload_all
* should generate everything from scratch
* https://dev-canvascdn1-com.s3.amazonaws.com/dist/brandable_css/brand
able_css_bundles_with_deps.jsonnestedother_key
should exist
to also test CNVS-23841:
* with node 0.11.x installed
* try to run `bundle exec canvas:compile_assets`
* it should fail fast and tell you it failed because
you don't have a new enough node
* it should not ambiguously fail with an error like
cannot find method 'parse' of undefined
Change-Id: I7a90560b8ef3c5ca173c4b5bc06e0681848c0099
Reviewed-on: https://gerrit.instructure.com/64473
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
since other projects have been known to upgrade npm on a jenkins node in
the course of a build, affecting subsequent canvas builds ಠ_ಠ
test plan:
npm install should be happy on npm v3
Change-Id: I6767dac7dea7c8cfb4dfabbf94a29f6cccb00c15
Reviewed-on: https://gerrit.instructure.com/63708
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
fixes: CNVS-22276
what this change does:
* changes it so if you have a 'host' set in canvs_cdn.yml,
when you run brandable_css it will push the css
files directly to s3 instead of writing them all to
disk.
* fixes the bug where brandable_css thought it had
to re-compile css files that have not changed
* changes the way we load css bundles that don't include
any branding or use any of the variant variables
(like: $use-high-contrast or $use-new-styles).
before, we generated a unique css file for each
variant and each brand for any of those bundles.
this will instead point everyone to same url if
the file uses none of those variables.
test plan:
* with no canvas_cdn.yml file:
* run compile_assets
* run it again, it should say "no changes" quickly
* the css in canvas should work
* now, rm -rf public/dist/brandable_css
* save a canvas_cdn.yml with proper s3/cloudfront settings
* compile_assets
* canvas should work and use the css that was uploaded
to s3 in previous step
* compile_assets again, it should say "no changes"
within a few seconds.
* if you can, delete a css file from s3 & run
brandable_css again. it should see that it needs
to regenerate that file and do so correctly.
when testing the css in the UI, especially make sure
to look for:
* try loading the equation editor in different variants,
(e.g.: high contrast, new styles, legacy) the css
for it should always be loaded from <cdn>/dist/brandable_css/no_variables/...
* keep your js console open, there should not be any 404s
* check the screenreader_gradebook
most of the changes actually happened in brandable_css:
https://github.com/ryankshaw/brandable_css/compare/6e0ddc59...master
when code-reviewing, please do a thorough scan of
those changes too.
Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838
Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838
Reviewed-on: https://gerrit.instructure.com/61495
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
This also upgrades Groups to use react 0.12
so that react-tools 0.13.3 can be used.
- Upgrades react-tools to 0.13.3
refs CNVS-22335
- Converts:
- Breadcrumbs
- Breadcrumbs Collapsed Container
- Column Headers
Test Plan:
- Make sure Breadcrumbs and Column Headers work in
New Files
- Regression test Groups
Change-Id: I37ce2909223ed5fb3cf09a8e7300d286a40fe838
Reviewed-on: https://gerrit.instructure.com/60109
Reviewed-by: Dan Minkevitch <dan@instructure.com>
Tested-by: Jenkins
QA-Review: Charles Kimball <ckimball@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
fixes: CNVS-22155
see: e1b5a8e5ec?diff=unified#diff-2b4ca49d4bb0a774c4d4c1672d7aa781R23
test plan:
say the path to your canvas-lms repos is in
/Users/ryan/code/canvas-lms
make a symlink that points to that in:
/Users/ryan/current
run `brandable_css`
it should work
Change-Id: I1f732a53e56ea376efe6cd7d54b3ae52178ac025
Reviewed-on: https://gerrit.instructure.com/59342
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
the way this was written, it used to fire off
a promise for every brand all at the same time.
I’ve changed it so the memory usage will be more
like `k * <# variants>` instead of
`<# of themes> * <# variants> * k`
so it will stay constant (on my machine ~500mb) and
not grow huge as we get more people that have made
themes. (where k is the memory it takes to
compile one sass file, and # themes is a constant,
in our case 6.
Change-Id: I1fa4b4410a1141b461019f0c614ba343ea73000c
Reviewed-on: https://gerrit.instructure.com/59182
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-22056
test plan
* compile assets
* run: bundle exec rake canvas:cdn:upload_to_s3
* go to canvas in the browser, look at the network
panel, things like common.js and css files
should be transferred as gzipped (so common.js
should not be 1.4mb)
this is also a great time to test the s3/cloudfront
settings that ops set up for us in OPS-1047, instead
of using the instructure_uploads_engineering bucket
and my own cloudfront distribution that you may
have been using. go to that ticket and take note
of the settings to use for testing/dev
and put them in config/canvas_cdn.yml
Change-Id: I9c1f8d6d9128554a38cd424b6e24947d7cd92208
Reviewed-on: https://gerrit.instructure.com/58975
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
everyone was getting build errors when they
were npm install'ing. it was because karma 0.10
depended on an out-of-date version of chokiadr
that does not compile against node 0.12
I also indicated that canvas is licenced agpl 3
so that you wouldn't always see an npm warning
about not having one.
also, let karma serve our css files
so if any javascript references them in our quit
tests, we don't see 404 warnings
Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56
Reviewed-on: https://gerrit.instructure.com/58584
Tested-by: Jenkins
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-21701 CNVS-21846
test plan.
* open theme editor and set just the "brand-primary" color.
* hit preview
* the background of the "global nav" on the left of
the page should be the color you set as brand-primary
Change-Id: I4781187db7543c31b71b25e414f8da6b3cda3578
Reviewed-on: https://gerrit.instructure.com/58310
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Product-Review: Jennifer Stern <jstern@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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>
Jeremy Neander