We compile sass using npm run compile-sass now, but the
script was still referencing the old (now deprecated) rake
task, which was causing updates to fail.
Change-Id: Idbedcf61ccccbdb0f1deb5907afb25d5d6650000
Reviewed-on: https://gerrit.instructure.com/40392
Reviewed-by: Nick Houle <nhoule@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Dave Donahue <ddonahue@instructure.com>
QA-Review: Dave Donahue <ddonahue@instructure.com>
...and print a message of what went wrong
test plan:
write some bad syntax in a sass file,
run `npm run compile-sass`
it should exit with non-zero status code
it should tell you what line of css caused the error
Change-Id: I0febb3286f6100993d5d2d53083d6a53719cbedf
Reviewed-on: https://gerrit.instructure.com/39385
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Colleen Palmer <colleen@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>
test plan:
* run `script/canvas_update`
* verify that the log output goes in /log
* verify that canvas was updated
* run `script/canvas_update -q` for QUICK_MODE
* verify QUICK_MODE's output is:
Quick mode enabled (assumes you have guard running and don't want to
generate docs)
Bringing Canvas up to date ...
Log file is /Users/lwilkins/sandbox/canvas-lms/log/canvas_update.log
Updating plugin vendor/plugins/canvasnet_registration ...
Updating plugin vendor/plugins/instructure_misc_plugin ...
Updating plugin vendor/plugins/multiple_root_accounts ...
Pulling Canvas code ...
Checking your gems (bundle check) ...
Gems are up to date, no need to bundle install ...
Migrating DB ...
Installing npm packages ...
Tips:
- 'bundle exec guard': auto-compiles JS files while developing
- 'script/delayed_job run': run delayed jobs in the foreground
NOTE 1) if you see
Gems are up to date, no need to bundle install ...
then `bundle install` will not be run
NOTE 2) after running this command, you'll be on master branch,
if you want to continue testing this script, checkout the
branch you pulled down again.
Change-Id: I99c3097d452128d6fffa31d25e3b7e57a438555e
Reviewed-on: https://gerrit.instructure.com/37423
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <braden@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
self.up works in rails2 and rails3, but up only works in rails3+
also tag the switchman migrations as RAILS3 only, now that they actually
run in rails2
Change-Id: I768c8e657e86de6504a40444d127e2d875ce6934
Reviewed-on: https://gerrit.instructure.com/35390
Tested-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
fixes CNVS-12182
test plan
- regression test on incoming mail
- use script/process_incoming_emails to manually trigger the processing
of incoming mail
Change-Id: Iccd74d8fe2b5af3d5eefe25a2736273e3bf559b0
Reviewed-on: https://gerrit.instructure.com/32794
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
fixes CNVS-12145
QA Test Plan:
- regression test incoming mail
- ensure that reply to discussion topic works
Change-Id: Iae88aa6da5cfe79e51609e233c05e356feacc198
Reviewed-on: https://gerrit.instructure.com/32610
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
fixes CNVS-12129
test plan
- regression on incoming mail
Change-Id: Ia9ab3419201c9fdbd89e2483a3fde51f54c7f982
Reviewed-on: https://gerrit.instructure.com/32594
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Joel Hough <joel@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>
refs CNVS-7597
render :json => thing will call ActiveSupport::JSON.encode(thing) unless
thing is a String. ActiveSupport::JSON.encode(thing) just calls
thing.to_json but with some circular reference checking that we want. we
may also want enhance ActiveSupport::JSON.encode to do additional
processing, and calling to_json straight up would bypass that.
in the cases where we do need to do the structural transformation before
passing to render :json (e.g. because of need to pass arguments), use
as_json to do structural transformation only, vs. to_json that does
serialization of the as_json result.
adds a rake task to lint the controllers to enforce as_json over to_json
in render json calls.
test-plan: heavy regression testing; no end behavior should change
(except a pair of serialization bugs that got fixed)
Change-Id: I7a91a9fe0eca70456bc5bca233f0ed6b27a54aaf
Reviewed-on: https://gerrit.instructure.com/23650
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
* automatically does with_exclusive_scope
* if the scope has an order or group by, use an alternate
implementation so it's not broken
* alternate methods are cursors (postresql only) or temporary
tables. if a transaction is already open, or we're on a slave,
prefer a cursor (even over the normal method, since the query
might be slow even without an order or group by)
test plan:
* migrations should still work (especially data fixups)
* lots of account reports use find_each; make sure they still run
Change-Id: If876b7b3401e6cda1d41f1c94b93af4810b78cf4
Reviewed-on: https://gerrit.instructure.com/22364
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Change-Id: I391010689a6488c49a75eaef586783793fc29613
Reviewed-on: https://gerrit.instructure.com/20889
Reviewed-by: Cameron Matheson <cameron@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
also added a warning to migration_lint about tables with no primary keys
test plan:
* run the migration; it should not fail
Change-Id: I67a065355bb516b84b00313725f079842bbd8974
Reviewed-on: https://gerrit.instructure.com/20705
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
- update the Gemfile to be 1.9 only, and raise an exception on wrong
ruby version
- remove RUBY_VERSION checks, replacing with the applicable code
- remove the FasterCSV compatibility shim, just use CSV now
test plan: trying to bundle install on ruby 1.8 or 2.0 should raise an
exception, specs should pass, canvas should work as normal on 1.9
Change-Id: I49088e9d227c59c6d5d5acb417c2df971129474a
Reviewed-on: https://gerrit.instructure.com/19806
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
replaced the mailman gem with custom code with more error
handling. this will allow the incoming message processor to
continue processing messages after encountering a message with
an encoding or parsing error. the broken messages will be moved
aside to a separate folder for later inspection.
fixes CNVS-4970
test plan:
- read up on the new incoming_mail.yml configuration settings.
- configure incoming_mail.yml with the test imap accounts
using legacy settings and check for regressions.
- reconfigure incoming_mail.yml to read from a directory.
- copy some testing email files into the configured directory.
test files should be a mix of:
- emails with encoding errors
- emails with syntax errors
- normal emails
- all of the normal emails should be processed normally
- all of the error emails should be moved into the error
subdirectory
Change-Id: I0f946a56b41492f007db2775aa6da3cdfa4fdd3f
Reviewed-on: https://gerrit.instructure.com/19729
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@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>
code fix, no test plan
Change-Id: Iff01e6523fb7d77a84d8e9829c5efbb2a5306a51
Reviewed-on: https://gerrit.instructure.com/18622
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Bracken Mosbacker <bracken@instructure.com>
Test Plan:
- Use the API to query courses/<id>/search_users
- You should be able to specify a search_term in the query that
narrows the results to matching users in the course
- You should be able to specify an enrollment_type of 'student'
or 'ta' etc. to narrow the results further. Multiple 'enrollment_
type's can be specified as a comma-separated list.
- You can limit the number of results with 'limit'
fixes #CNVS-2324
Change-Id: Ic87ff797028f71b478de6397557b142d7d0fe6b5
Reviewed-on: https://gerrit.instructure.com/16640
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
rspec-rails no longer includes it. use spork instead
Change-Id: Ibdd318970e45f5073ed8e498c9bbb184a8ebf7cc
Reviewed-on: https://gerrit.instructure.com/15652
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
don't let guard break ruby-debug
add BARE_SERVER shortcut
don't duplicate the tailing of delayed job output -- the server is
already tailing log/development.log, so tell the job daemon not to tail
it too
Change-Id: I23f8b9b413e99f515804819292b3ae15a598290d
Reviewed-on: https://gerrit.instructure.com/9796
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
test plan: start up script/server in development mode, and verify that
jobs are running and guard catches changes to files. you should also be
able to hit enter to make guard re-compile all.
Change-Id: I064588e58d09dd770110d046b86337a0e988017a
Reviewed-on: https://gerrit.instructure.com/9593
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
and some work on delayed_jobs refactoring
refs #4226
Change-Id: I21a91a44368e77aef4a75e0d30cefe252a901691
Reviewed-on: https://gerrit.instructure.com/3640
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
* Uses Mailman gem
* Can be configured for POP3, Maildir, or stdin (push from mailserver)
* Maildir can be chained with fetchmail or similar to support IMAP
* Can be run as part of the job server, or as a separate process
Change-Id: I000000000000000000000000000001
Reviewed-on: https://gerrit.instructure.com/2971
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
right now, the documentation tells people to change script/canvas_init, which
kinda sucks for people hoping to upgrade by doing git pull.
this seems sort of hacky - i'm open to suggestions.
Change-Id: I66bf3deb2f51c22c23c1963369c6ab3e5f391d33
Reviewed-on: https://gerrit.instructure.com/2145
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>