Using the parallel_tests gem allows us to parallelize more
and a bit simpler. Removes headless stuff now that we don't
use it anymore, comments out video recording code since it
doesn't work, removes all knapsack code.
flag = none
Test Plan:
Jenkins rspec and selenium builds pass
rspec and selenium builds copy results to html publisher
rspec and selenium have nodes split into processes
Change-Id: Ibd00eba77f8193be5eadd41aef1e0617c9ae470c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/227677
Reviewed-by: Jacob Powell <spowell@instructure.com>
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
This will fix some issues with jenkins builds failing if the
patchset is behind some newer graphql changes, as well as allowing
us to include content defined in our plugins in the graphql.schema
file.
Test Plan:
- Jenkins passes
fixes USERS-210
flag = none
Change-Id: Ic44849ee57955e0b90395661a66f6d5840a38e87
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/222029
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Steve Shepherd <sshepherd@instructure.com>
Product-Review: Landon Gilbert-Bland <lbland@instructure.com>
This is in an attempt to
1. Prevent unpredictable behavior when
running docker-compose without specifying
docker-compose files (intentionally or
unintentionally *This is exactly a problem
I found that caused issues, running the defaults on accident)
2. Follow more closely what other projects
are doing, they don’t have the override committed
3. Follow typical industry standard,
from what I’ve seen, such as
https://blog.sentry.io/2019/02/28/exception-perceptions-docker
test plan:
Running ./script/docker_dev_setup.sh with no
docker-compose.override.yml
in the root directory will print the message
"Copying default configuration from
docker-compose.override.yml.example to
docker-compose.override.yml" and copy the file in.
Running ./script/docker_dev_setup.sh with an existing
docker-compose.override.yml will simply print
"docker-compose.override.yml exists, skipping
copy of default configuration"
Also check that the documentation changes
sufficiently explain the new
process and what to expect.
The file shouldn't be in the root of the
directory in the repo anymore,
in order to prevent unwanted default behavior
(requires explicit naming
of docker-compose files)
There should be a
docker-compose.override.yml.example in the config
folder for reference.
• Add `docker-compose.override.yml` to `.gitignore`
• Leave a copy of the current
`docker-compose.override.yml` in
`config/docker-compose.override.yml.example`
• Delete `docker-compose.override.yml`
from the root directory
fixes CORE-3409
Change-Id: I9cffeb52f2cc233061f78de10fcb240c09743542
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/214116
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
Reviewed-by: Robert Lamb <rlamb@instructure.com>
QA-Review: S. Jacob Powell <spowell@instructure.com>
Product-Review: S. Jacob Powell <spowell@instructure.com>
Change-Id: I9a2da0fe619170e6a297ad5d1b9dd3e11daf3782
Reviewed-on: https://gerrit.instructure.com/206054
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
fixes COMMS-2290
flag Assignments 2
Test Plan:
- create a media upload assignment
- in a2 as a sutdent go submit an assignment
- notice a video upload button
- click button
- notice the modal is shown and you can drag and drop video files
or record yourself
- close modal
- notice no console errors or crashes
Change-Id: I9a6184efb99aa05d0d634d2744cca00abf5ae26e
Reviewed-on: https://gerrit.instructure.com/204375
Tested-by: Jenkins
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
closes: CORE-2904 CORE-2905 CORE-2906
This will send the XHR requests for the dashcards and for all the stuff
in the planner dashboard sooner. As in, as soon as the html document
comes back from the server, instead of waiting until all the js bundles
have downloaded and executed. This should remove a round-trip from
the dashboard page and you should notice the planner and dashcard
dashboards complete loading a lot faster. By sending the requests
sooner, our app servers can work on them while the browser is
downloading all the rest of the JS that it needs to run the page. And
by having our app servers work on that at the same time the browser
works on the JS, the entire page will complete loading faster.
Test plan:
* go to the planner dashboard
* you should see 4 requests with the type “fetch” in the network panel
in the waterfall right at the same time the html document is returned
* you should not see any more XHRs sent from axios on page load for the
planner dashboard (it should use the prefetched ones)
* in a prod environment, where you have multiple app server processes
handling requests, the planner dashboard should complete loading a lot
faster
* In that same prod like environment, go to the dashcard dashboard
* same thing, it should issue a “fetch” request right with the html
document comes back from the server and not issue an second
XHR once the JS is loaded.
* it should be complete loading significantly faster too.
Change-Id: I0503c1a4d913fd1baa4dad22b9a88333ff747c0d
Reviewed-on: https://gerrit.instructure.com/192161
Tested-by: Jenkins
QA-Review: Mysti Lilla <mysti@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
This gets canvas planner and canvas-rce on babel 7, which is a
prerequisite to canvas doing the same. Also, by not depending on the
Kitchen sink of ui-presets, it cleans a ton of unused stuff from our
node_modules/yarn.lock. It was originally 2 different commits but
in order to get the yarn.lock right, we have to do them all as one.
This also made it so we needed to have less “resolutions” in our
package.json since the newer versions of those things work fine with
the newer version of babel
So there are 2 test plan areas:
1. Canvas-planner
Closes: CORE-2575
Test plan:
* smoke test to make sure everything in canvas-planner still works/looks
like it used to in the canvas ui
* make sure the translation task (yarn check-transifex) still works
canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset
2. canvas-rce
Closes: CORE-2576
Test plan:
* smoke test the RCE editor
* theming should still work/look exactly as before
* make sure all the various build tasks (eg yarn test, test:coverage,
debug, lint, extract, etc) all still work as before
Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5
Reviewed-on: https://gerrit.instructure.com/183877
Tested-by: Jenkins
Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com>
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This should pick up coverage from both karma and jest
in Canvas proper. It should also pick up coverage from anything under
packages/*
closes CORE-1265
Test Plan:
- Run `COVERAGE=true yarn test`
- Coverage reports (coverage-final.json) should generate in all
packages such as (canvas-planner) as well as in coverage-karma
and coverage-jest
- Run `yarn run test:coverage`
- coverage-js folder should be generated. Opening index.html
should show the full coverage report
- Remove coverage-{js, karma, jest} and
packages/canvas-planner/coverage as well as .nyc_output to get back
to a clean state
- Run `RUN_TESTS_FIRST=true yarn run test:coverage`
- All tests should run and generate the appropriate report just
like the last time in coverage-js
Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066
Reviewed-on: https://gerrit.instructure.com/146098
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Fixes PLAT-3550
Test Plan:
- Verify there is no 'API Token Scopes' under OAuth2
- Verify there is only one link 'API Token Scopes' under Resources
- Verify there is no code left related to generating the 'API Token
Scopes' table under OAuth2
Change-Id: Ib00a4aeec102eafc22169ac5322b581fef797a0b
Reviewed-on: https://gerrit.instructure.com/155247
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Closes PLAT-3394
Test Plan:
- Run the `doc:api` rake task
- Navigate to /doc/api/index.html and verify there
are two new links in the OAuth2 section ("Developer
Keys" and "API Token Scopes")
- Verify both links work
- Verify the token scopes documentation has a table
for each scope group and includes all Canvas
scopes
- Verify "Resources" documentation pages now display
the scope along with each API endpoint
Change-Id: I2fea0ff531744dbaf63d24619b3c0e9655a25a7a
Reviewed-on: https://gerrit.instructure.com/151010
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Tested-by: Jenkins
Product-Review: Jesse Poulos <jpoulos@instructure.com>
fixes PLAT-3311
test plan:
* run the rake task "doc:api"
* request the scopes from api/v1/accounts/:account_id/scopes
- you should get back a json object that includes the localized name
* request the scopes from api/v1/accounts/:account_id/scopes passing
the query param "group_by=resources_name"
- you should get back a json object with the scopes grouped by
localized resource_name
Change-Id: I2cab1822baef7cdda6471096153d60d4f7fe1e2b
Reviewed-on: https://gerrit.instructure.com/150233
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Test Plan:
- follow the instructions in spec/contracts/README.md to run
the live events contract tests locally
- follow the instructions in
spec/contracts/service_providers/canvas_lms/README.md to run
the "Generic Consumer" Canvas API contract tests locally
Change-Id: I316747f53731f411ab82432587596e335c2fd059
Reviewed-on: https://gerrit.instructure.com/149766
Reviewed-by: Tucker McKnight <tmcknight@instructure.com>
Tested-by: Jenkins
Product-Review: Michael Hargiss <mhargiss@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
this is to prevent canvas from copying everything in canvas-planner’s
node_modules dir into /node_modules/canvas-planner/node_modules
this will mimic the exact same behavior that pushing it to the npm
repository and pulling it from there in canvas’s package.json
test plan:
* do `ls node_modules/canvas-planner/node_modules/jest*`
* you should get: ls: node_modules/canvas-planner/\
node_modules/jest*: No such file or directory
Change-Id: Ie428b3d0a5d6cc1d9bec89ae00adb3d451dfc916
Reviewed-on: https://gerrit.instructure.com/139907
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CORE-949
this also upgrades us to use what was on canvas-planner master
as of 1pm on 2/1/2018 (specifically 9569cc1)
test plan:
* canvas planner should work
* all automated builds should pass
Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2
Reviewed-on: https://gerrit.instructure.com/135947
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: 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>
Derek Bender