closes: CNVS-31785
test plan:
all builds should pass
Change-Id: I2925934692a3d2f115f1289d7b50cb72d8cb907f
Reviewed-on: https://gerrit.instructure.com/104492
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
just check in main.coffee, it pretty much never changes (especially since
the ember srgb will diaf soon)
this is (hopefully) one of the last pieces of the webpack puzzle
test plan:
* webpack and requirejs builds should be happy
* srgb should boot up in both
Change-Id: Icc1a6ad811cffca5ef18a6858d9103c9bbccf037
Reviewed-on: https://gerrit.instructure.com/103352
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Change-Id: I5879e3944d64eb67eb73e885174c83c808abc323
Reviewed-on: https://gerrit.instructure.com/103029
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes CNVS-34793
don't warn about it anymore, don't bother with a separate lockfile
(just make people suffer through installing rails via git), and
bump the rails branch a bit to pick up a deprecation warning fix
Change-Id: I430e5c97adf2f7db5a9badc2a13ba4d8b4161e5c
Reviewed-on: https://gerrit.instructure.com/101275
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes: CNVS-31779 [webpack] bundle file size
test plan:
* using webpack, look at the network panel in
the chrome developer console.
* the total ammount of javascript loaded for any
given page should be much less than before this commit
and about on par with what requireJS loads for the same page.
* use chrome network panel to throttle to "Regular 3G"
* from both a clean cache and a primed cache:
* make sure that the total time to render the page
is about on par with requireJS
first change: load webpack chunks from CDN
fixes: CNVS-32261
test plan:
* run `npm run webpack-production`
* check your page, it should load js files and chunks
from the same hostname the page is served from.
* now set a host: in config/canvas_cdn.yml
(for testing locally, I just set it to http://127.0.0.1:3000,
* restart rails and reload the page, now the scripts and
chucks should come from that new hostname
second change:include fingerprints in webpack bundle and chunk filenames
closes: CNVS-28628
with this change we don't need to run `gulp rev`
after running webpack and we can load both the bundle
and chunk files safely from the cdn, since they will
have content-based fingerprints so we can tell
browsers to cache them forever. (we set those
http caching headers in lib/canvas/cdn/s3_uploader.rb:53)
test plan:
* for both dev and production
* run `npm run webpack` (or `npm run wepack-production`)
* with a cdn configured in canvas_cdn.yml, run:
RAILS_ENV=<dev or prod> bundle exec rake canvas:cdn:upload_to_s3
* check to make sure that the page loads the webpack js,
that there are no errors, and it all came from the cdn
third change: properly handle moment locale & timezone in webpack
test plan:
(see application_helper_spec.rb)
* set a non-default user timezone, context timezone
and locale
* dates should show up in your timezone and and
the date helper strings should be in your language
better handling of moment custom locales
closes: CNVS-33811
since we now have hatian and maori, we need to do this in
a way that is not just a one-off for maori
test plan:
* set your locale to maori
* in webpack & requireJS make sure dates show up right
Change-Id: I34dbff7d46a1047f9b459d5e1c0d141f435d42fb
Reviewed-on: https://gerrit.instructure.com/95737
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
If you have a docker-compose.override file you'll want to
move it somewhere else.
mv docker-compose.override.yml docker-compose.`whoami`.yml
Once you've updated your override file to the version 2 syntax, you
should add it to the COMPOSE_FILE environment variable. Probably in a
.env file in the project root.
Test plan:
You'll need to remove your existing canvas containers and volumes to
fully test this.
to do so run this **BEFORE** you checkout this patchset
```
docker-compose down
docker-compose ps -q | docker rm
docker volume ls -q | grep canvaslms | xargs docker volume rm
```
then you should be able to get up and running using the following
```
cp docker-compose/config/* config/
dc build
dcr web bundle exec rake db:create db:initial_setup
dc up
```
You should be able to access canvas like normal
Change-Id: Ia7ff76cfdd4f46278fc1cb2a03969fdadaa4a434
Reviewed-on: https://gerrit.instructure.com/91008
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brad Horrocks <bhorrocks@instructure.com>
fixes SD-1724
in previous refactorings, plugin and ember js specs stopped running, and
regular specs started running twice
test plan:
1. confirm that ember specs run and pass now (110 of them)
2. confirm that more regular specs run than before (cuz plugins)
3. confirm that the regular specs don't run twice (unless it does the
retry thing)
4. `sudo -u clay test it every which way`
Change-Id: I24ac56b9d3082e25d15f06193c9a9e5c4313b7a7
Reviewed-on: https://gerrit.instructure.com/94305
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Change-Id: Id1900160375644ea33badaa9d9f9185fab6b81ac
Reviewed-on: https://gerrit.instructure.com/92726
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
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>
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>
fixes CNVS-26161
test plan:
- with an RCS set up
- with remote RCS both on and off
- go to accounts/:account_id/settings
- go to the announcments tab
- make an announcment
- it works
- make an announcement with missing message
- the error message works
- edit an assignment with a missing description
- that error message works too
Change-Id: I4c3fc83fb59097f2ce5d4d0b868253c264ed477c
Reviewed-on: https://gerrit.instructure.com/69609
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
it was the rails 2 to 3 migration helper
Change-Id: I826fa7b260b27d1bea8afcd6c6ea860c9d0a290c
Reviewed-on: https://gerrit.instructure.com/68274
Reviewed-by: Rob Orton <rob@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Change-Id: I601320861bed38e6a37af17a8c65fa526735a9ac
Reviewed-on: https://gerrit.instructure.com/68255
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
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>
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>
Adds a docker-compose.yml file, some containers for dependencies, and
some docker-compose-friendly config files. See
doc/development_with_docker.md for instructions on how to use.
Change-Id: I5eaee8a3e3c84bb608282bfd44ec7d49a123ef5f
Reviewed-on: https://gerrit.instructure.com/45508
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Addison Higham <ahigham@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins
Product-Review: Zach Wily <zach@instructure.com>
QA-Review: Zach Wily <zach@instructure.com>
it to the gitignore file
Change-Id: Ic17f80370a000ed3e9800a5d9fb9a0547a30cde9
Reviewed-on: https://gerrit.instructure.com/47782
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Colleen Palmer <colleen@instructure.com>
closes: CNVS-17331 CNVS-14993
refs: CNVS-17332
This is the first step to having a full theme editor where
accounts can pick their own color scheme in a UI and all of
canvas will be branded to their school colors.
test plan:
* copy config/brand_variables.scss.example to config/brand_variables.scss
* recompile sass
* users in accounts that have "new styles" or "k12" turned on that have
not turned on "high contrast". should see a new purple-orange canvas.
* but users that have turned on the "high_contrast" feature or accounts
that have not turned on either "k12" or "new styles" should not.
Change-Id: I16342d43b56e49d52fbee8fa5c6a0fd57ae6e602
Reviewed-on: https://gerrit.instructure.com/46085
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Colleen Palmer <colleen@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>
This commit brings in canvas_quiz_statistics, a client app that can be
embedded in Canvas.
Closes CNVS-14781, CNVS-14846, CNVS-14847, CNVS-14850
> What's done
- full build integration, meaning the app runs with ?optimized_js=1:
+ JavaScript "built" source gets piped into the r.js build pipeline
like any other Canvas JS source in public/javascripts/*
+ SCSS sources get picked up by the sass-compiler like Canvas style
sources and they get compiled from the grounds-up
+ I18n: phrases are extracted properly, with default values and
options, by our i18n rake tasks
- new rake task js:build_client_apps that builds client apps and
injects them as input to the rest of the JS build process
- support for using Canvas JS packages, like d3, jQuery, and Backbone
- support for using Canvas SASS variables & helpers
- super i18n support: use raw I18n.t() calls like you are in Canvas,
with development-time interpolation, as well as super new
Handlebars-like block-style translations in React, perfect for very
long phrases (mini-articles)
> Docs and References
The code was originally developed in its own github repository. While I
won't be pushing code to that repo anymore, the Wiki will still house
the docs until we find a better place.
- Repo: https://github.com/amireh/canvas_quiz_statistics
- Development guide: http://bit.ly/1sNOhER
- Integration guide: http://bit.ly/1m9kA9V
> TESTING
- login as a teacher
- go to /courses/:course_id/quizzes/:quiz_id/statistics_cqs
+ make sure you see something that looks like the Ember stats
+ click one of those little "?" help icons, you get a dialog:
- verify the contents within the dialog are actual English text,
not code gibberish
- there's also a link at the end of that dialog, click it and
verify it takes you to an Instructure help article
- build the assets: `bundle exec rake canvas:compile_assets` then:
+ add ?optimized_js=1 to the URL and reload the page:
- verify the app still works
Change-Id: Ic474650dfb06a1c22869ed9680dd04d1ca0f651d
Reviewed-on: https://gerrit.instructure.com/39105
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Hannah Bottalla <hannah@instructure.com>
Reviewed-by: Adam Ard <aard@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
also switch rails3 lockfile to the default, so the spring binstub can
use the default lockfile and see itself
Change-Id: Id10cbc3df010671a59c73137a77583e2c2e0e5a8
Reviewed-on: https://gerrit.instructure.com/37802
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Sutter <csutter@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
closes CNVS-12609
test plan:
- make sure rake i18n:generate still works
- basic regression of i18n in canvas
Change-Id: I882c7b6f197d65aa673a22225ae6a87ee4431aa0
Reviewed-on: https://gerrit.instructure.com/33760
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Refactoring the generation of quiz question statistics into its own gem.
This patch adds support for Essay question statistics.
Closes CNVS-12725
TEST PLAN
---- ----
- create a quiz with an essay question
- perform an API request to retrieve the quiz statistics
- ensure that the following metrics are generated and correct:
- "graded": number of students whose answers have been graded by the
teacher
- "full_credit": number of students who received a full score
- "point_distribution": a list of scores and the number of students
who received them (so if 2 students got graded for 3 points, it
should have a key of 2 and a value of 3), un-graded submissions
should be keyed under null
- "responses": number of students who answered the question
(wrote anything)
- "user_ids": IDs of those students
- documentation for QuizStatistics -> Essay should be updated with the
new stats
> Other things to test
- verify that the old statistics page still renders:
/courses/:course_id/quizzes/:quiz_id/statistics
- verify that you can still generate both student and item analysis
CSV reports
API endpoint for quiz stats:
/api/v1/courses/:courseid/quizzes/:quiz_id/statistics [GET]
Change-Id: Ib15434ff4cef89ac211c1f4602d1ee609ef48ec4
Reviewed-on: https://gerrit.instructure.com/33990
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
fixes CNVS-11426
The UI/UX team *really* wants to start doing some major style changes
to the canvas interface. Because it is a very visual change and especially
because we've let people hack the crap out of canvas styles with
their own css override file, any changes we do need to be behind a
feature flag so an institution can opt-in when they are ready.
This commit does some trickery so we actually create 4 different versions
of every stylesheet. one for each variant in:
legacy_normal_contrast legacy_high_contrast
new_styles_normal_contrast new_styles_high_contrast
and then sets the $use_new_styles and $use_high_contrast sass variables
accordingly in each.
now, in any sass file, you can do things like:
@if $use_new_styles {
background-color: red;
} @else {
background-color: blue;
}
@if not $use_high_contrast{
font-size: 12px;
}
test plan:
* in a production (minified assets) environment, ensure you see:
<link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page
* go to the account settings page for the domain_root_account you are on
* turn on the "Use New Styles" feature
* now verify that <link href="/assets/common_new_styles_normal_contrast.css...
is in the <head>. There should not be any visible differences because we do
not have any styles that target specifically $use_new_styles yet.
* now, go to /settings and turn on the user feature for "Use High Contrast Styles"
* verify that <link href="/assets/common_new_styles_high_contrast.css..
is in the <head>
* again, turning that on will not actually change the way anything looks,
the next commit (g/32863) will take care of that
Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418
Reviewed-on: https://gerrit.instructure.com/31881
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>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
closes CNVS-11294
test plan:
- enable ember quizzes
- ensure that existing ember quizzes continue to work
- all existing ember tests should continue to pass
Change-Id: I4f56b1267504533be8332520ea5f77d2fa566263
Reviewed-on: https://gerrit.instructure.com/33105
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Jason Madsen <jmadsen@instructure.com>
Change-Id: I2af3335578140c943b962dee7fa506bba62948d3
Reviewed-on: https://gerrit.instructure.com/32171
Reviewed-by: James Williams <jamesw@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@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>
test plan:
- run "rm -rf spec/javascripts; git checkout HEAD --
specs/javascripts" to reset your compiled javascript tests.
- run rake js:generate_runner
- JS tests should pass
- # of JS tests should be the same as they are on master before this
commit
Change-Id: I936aec8a8a5e2cc739e09757c622f300e99c72ef
Reviewed-on: https://gerrit.instructure.com/25615
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Bryan Madsen <bryan@instructure.com>
QA-Review: Bryan Madsen <bryan@instructure.com>
also added styles to make .form-controls look
good in dialogs.
closes #CNVS-4302
Change-Id: Ibe54ee4046ac255b0b0ea83d32afc88e4a820464
Reviewed-on: https://gerrit.instructure.com/19331
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
test plan:
- make sure you have the coffee binary from npm:
`npm install -g coffee-script@1.6.2`
- run rake js:generate, make sure all coffeescript still compiles
correctly
- open a coffeescript file and make sure it still gets automatically
compiled when saved by guard.
- rejoice at the arrival of source maps.
Change-Id: I06ce9e83a76be9d4cc0e2b2c80566a0db19f9d7e
Reviewed-on: https://gerrit.instructure.com/18842
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
This can successfully load rails console and rails server. There are
many, many problems still. The idea is this won't change anything under
rails 2.3, it's all backwards compatible.
closes CNVS-4711
test plan: `touch RAILS3` in your Canvas Rails.root directory. The run
`bundle update` and verify that you get rails 3 installed. Run `bundle
exec rails c` to load console or `bundle exec rails s` to start a
webrick server. You can login, though the dashboard currently breaks.
Also jammit isn't working yet.
But more importantly, Rails 2.3 should still work same as ever. All
tests should pass, and a basic regression sanity check would be good too.
Change-Id: Idd6f35de88adde84cd2db3a650f44b71bd6e9684
Reviewed-on: https://gerrit.instructure.com/18453
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
don't need this, plus ** isn't supported on all platforms
Change-Id: I69eb02143624bdf82497dcd997eb0e8c834ac51f
Reviewed-on: https://gerrit.instructure.com/17024
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
Reviewed-by: Stanley Stuart <stanley+gerrit@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
remove a lot of things that are no longer relevant, DRY it up a bit and
make it a bit more explicit (root paths, better globbing)
test plan:
1. `git status`
2. all your previously ignored stuff should still be ignored, except
perhaps editor stuff, which should really go in .git/info/exclude
Change-Id: I0c0f6dc3cd969bb6f90f26c1af83f1bd7ef852e4
Reviewed-on: https://gerrit.instructure.com/16994
Reviewed-by: Joe Tanner <joe@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
allows plugins to have a bundle get auto-loaded with a corresponding
canvas bundle. uses require.js' include mechanism in build.js (when
optimized) and a rails helper tweak (when not optimized).
this happens automatically based on the path, e.g. the foo plugin's
"bundles/extensions/bar" will get automagically included whenever the
regular "bar" bundle is required.
removes the need for a plugin-level build.js, and auto-generates bundle
module definitions in canvas' build.js (via erb). this handles all
regular bundles both from canvas and plugins.
also fixes plugins so that bundle dependencies get optimized. plugin
paths are created automatically, so this means we can remove things like
this from plugin bundles and specs:
require.config
paths:
myplugin: "/plugins/myplugin/javascripts"
test plan:
1. use canvas in development mode, it should work
2. use canvas in optimized JS mode, it should work
i. confirm that all scripts are optimized
3. use canvas in development mode with plugins w/ JS, it should work
4. use canvas in optimized JS mode with plugins w/ JS, it should work
i. confirm that all scripts are optimized
5. add a bundle extension in a plugin (e.g. create
bundles/extensions/conversations in plugin foo)
i. confirm that the extension code runs in development mode
ii. confirm that the extension code runs in optimized JS mode
Change-Id: If8507afdbabab4ae8966f7db79d9b0e2284034db
Reviewed-on: https://gerrit.instructure.com/11238
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Ryan Shaw