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>
This makes a number of changes to get the compilation compatible with
node 12 and iojs.
- removes loom (no longer used)
- updates karma dependencies to more recent versions
- minor css change to make sass compilation work with node-sass
(lib-sass)
test plan:
- should be able to compile assets with node 12 and iojs
- JS specs still pass
Change-Id: Id4a0628ff0c6dd09e622d02329a4400d60459ec2
Reviewed-on: https://gerrit.instructure.com/49493
Tested-by: Jenkins
Reviewed-by: Nick Houle <nhoule@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
QA-Review: Cameron Matheson <cameron@instructure.com>
this will allow us to enforce linting in the build
also ignore plugins' vendored javascript
Change-Id: Ibf6e9b73e0051a0b581ee52b641f9ff00dd6b2f2
Reviewed-on: https://gerrit.instructure.com/46351
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
no significant issues/vulnerabilities fixed in this commit, rather this is
a catch-all so we can enforce linting in the build.
to better understand what's going on here, see the following:
* public/javascripts/.xssignore
* script/xsslint.js
* https://github.com/jenseng/xsslint
high level summary of what's going on in this commit:
1. .html/.append/etc. now know what to do with a SafeString ... in many
cases we now put a $.raw around an .html argument to tell the linter
it's ok
2. although translation is an unlikely attack vector, we now htmlEscape
I18n.t calls used in html snippets, etc. this is a good thing, as it
ensures we don't create a vulnerability later (e.g. by interpolating
user content into a translation)
3. many vars were renamed (Html suffix, $ prefix) to let the linter know
it's something that was manually vetted
4. in some cases, rather than renaming or creating a superfluous var,
we add special xsslint comment overrides
test plan:
specs should all pass
Change-Id: Ide1df825b798d1b0c468a5308802543bf716c0d7
Reviewed-on: https://gerrit.instructure.com/46097
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Derek Hansen <dhansen@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
this swaps out our "parsing" with i18nliner-js
also remove localization abilities of I18n.beforeLabel, since it's not
worth the trouble to support. it can still be called to format a string.
notable changes/fixes in generated yml:
1. client_apps are picked up by i18n:rake so they'll get translated...
due to the old short-circuiting logic (`rc = rc && ...`), it would
stop processing scripts within a particular file after the first one
it found without an I18n.t
2. we no longer incorrectly double-escape special chars in our js strings
(e.g. newlines are actually newlines, not a literal "\n")
test plan:
1. verify string extraction:
1. `rake js:generate i18n:generate` before and after this commit
2. confirm `config/locales/generated/en.yml` is identical, except the
notable changes/fixes listed above
2. verify js translation file generation:
1. `rake i18n:generate_js` before and after this commit
2. confirm the files in public/javascripts/translations are identical
3. verify client_app checker still works:
1. `cd client_apps/canvas_quiz_statistics/`
2. `grunt check_i18n`
Change-Id: Ic8ad058bee1c9476f42916f10b612c1c08863fe3
Reviewed-on: https://gerrit.instructure.com/42809
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Product-Review: Michael Ziwisky <mziwisky@instructure.com>
QA-Review: Michael Ziwisky <mziwisky@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
the newer version we were using (0.9.5-rc1) seems to have a bug
that causes it to drop 'left' and 'right' styles
test plan:
- the 'HTML Editor' and 'Rich Content Editor' links on the wiki
page editor should appear on the right side and should not
overlap the page title
fixes CNVS-15760
Change-Id: Icab9be6b25114485f0f5d9990b1eb3c1d600b35f
Reviewed-on: https://gerrit.instructure.com/41720
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
after many steps towards this moment, we're finally here
This yanks sass and compass out of canvas-lms
completely and instead uses the libsass based
node-sass to compile our SASS files.
wins:
It is WAYYY faster!
as in, < 10 seconds to recompile all css in canvas
(compared to the 5+ minutes it used to take)
It is all in JS, helping use move to a completely
nodeJS based fronted tooling workflow.
next steps:
remove jammit: we don't need an assets.yml file
since node-sass can output compressed css for us
and we use sass to do all of our @import'ing of other
files (@colleen calls those "compiler" sheets), this
would simplify and speed up fronted asset building
even more
use gulp/broccoli/whatev to do cached, incremental builds
test plan:
all outputted css should look exactly the
same as it used to.
run `npm run compile-sass`, make sure it works
and is way faster than `rake css:generate` used to be
Change-Id: I7d865ea6b3e374cdc27a883d2019a4c15746c0e2
Reviewed-on: https://gerrit.instructure.com/38416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Include compute-cluster in "dependencies" so `npm install --production`
works for building assets.
Test plan:
- run rm -rf node_modules && npm install --production
- run bundle exec rake canvas:compile_assets
Change-Id: Ie5b1d387608f24b59a736dbeb974cb1ec710cfbd
Reviewed-on: https://gerrit.instructure.com/34302
Reviewed-by: Jason Madsen <jmadsen@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
...by parallelizing everything I could
fixes: CNVS-12362
`time bundle exec rake canvas:compile_assets`
(on my I7 2.3GHz macbook pro)
before: "322.56s user 26.62s system 173% cpu 3:21.05 total"
after: "425.91s user 30.71s system 413% cpu 1:50.35 total"
If you ever find yourself needing to run everything all
sequentially (and not in multiple threads), you can
set the environment variable CANVAS_BUILD_CONCURRENCY=1
by default it will use all the cores your system has
You're welcome, anyone that has ever had to build canvas
or wait for jenkins to run :)
Test Plan:
* run "time bundle exec rake canvas:compile_assets"
* checkout this code
* run it again
* verify that it is faster, and everything works
Change-Id: Ib01506bc9638e86f4a329284458706279ef751ab
Reviewed-on: https://gerrit.instructure.com/33127
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
Change-Id: I26809102e68d1be5951a2eb446f2f4a0aeb40e08
Reviewed-on: https://gerrit.instructure.com/31707
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
- js:generate_runner now generates common files to be used by different test runners
- js spec file order now shuffled to better expose dependencies
- fakeENV now returns two methods: setup and teardown
- stock tinymce 3 files are now wrapped for AMD
test plan:
- tinymce should work the same
- js:test rake task should run tests
- js:build task should work as normal (using new location of r.js)
- test results should successfully send to firework
Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2
Reviewed-on: https://gerrit.instructure.com/29297
QA-Review: Shawn Meredith <shawn@instructure.com>
Tested-by: Shawn Meredith <shawn@instructure.com>
Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
- first install new npm modules `npm install`
- add node_modules/.bin/ to your path or install
loom globally with `npm install -g loom` or
call the binary directly from node_modules with
`node_modules/.bin/generate <args>`
to generate objects for your ember app run
`generate <generator> <app>/<name> <options>`
examples:
generate model quizzes/user name:string
generate component inbox/modal
generate route inbox/messages/message
test plan:
- none, we aren't set up to test node code but
loom itself is well tested
Change-Id: Ibdf1d6307cbf5f2eb651d0f45aa0f94229b57814
Reviewed-on: https://gerrit.instructure.com/23387
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
"Trivial" JavaScript / CoffeeScript changes
--------------------------------------------------
For the most part, all javascript was simply
wrapped in `require` or `define`. The dependencies
were found with a script that matched regexes in
the files, it errs on the side of listing too many
dependencies, so its worth double checking each
file's dependencies (over time, anyway).
i18n API changes
--------------------------------------------------
No longer have to do I18n.scoped calls, just
list i18n as a dependency with the scope and it's
imported already scoped
require ['i18n!some_scope'], (I18n) ->
I18n.t 'im_scoped', 'I'm scoped!'
JS bundling now done with r.js, not Jammit
--------------------------------------------------
We don't use jammit to bundle JS anymore. Simply
list dependencies for your JS modules in the file
and RequireJS handles the rest.
To optimize the JavaScript, first make sure you
have node.js 0.4.12+ installed and then run:
$ rake js:build
The app defaults to the optimized build in
production. You can use non-optimized in
production by putting ?debug_assets=true in the
url just like before.
You can also test the optimized JavaScript in
development with ?optimized_js=true.
Significant changes
--------------------------------------------------
These files have "real" changes to them (unlike
the JavaScript that is simply wrapped in require
and define). Worth taking a really close look at:
- app/helpers/application_helper.rb
- app/views/layouts/application.html.erb
- config/assets.yml
- config/build.js
- lib/handlebars/handlebars.rb
- lib/i18n_extraction/js_extractor.rb
- lib/tasks/canvas.rake
- lib/tasks/i18n.rake
- lib/tasks/js.rake
Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7
Reviewed-on: https://gerrit.instructure.com/6986
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Ethan Vizitei