ylqjgm
/
canvas-lms
mirror of https://github.com/instructure/canvas-lms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
canvas-lms/lib/brandable_css.rb

188 lines
9.4 KiB
Ruby
Raw Normal View History

fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
require 'pathname'
require 'yaml'
don't proceed like normal if brandable_css cmd fails fixes: CNVS-23632 it turns out, the way I was doing this ruby would create a sh subprocess and brandable_css would be it's subprocess. so $? would be the sh process (which would always exit successfully). test plan: * in theme editor, try to preview a theme * but before you do, do something to make it so brandable_css will fail (like uninstall node or rm -rf node_modules or use activity monitor to view active processes and kill brandable_css when it appears) * it should say "something went wrong generating..." instead of continuing like everything worked Change-Id: I3c80c18381bb52c71d4b79d5b151988d6cf5cc3b Reviewed-on: https://gerrit.instructure.com/63948 Reviewed-by: Jacob Fugal <jacob@instructure.com> Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-09-25 01:37:49 +08:00
require 'open3'
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
module BrandableCSS
APP_ROOT = defined?(Rails) && Rails.root || Pathname.pwd
CONFIG = YAML.load_file(APP_ROOT.join('config/brandable_css.yml')).freeze
BRANDABLE_VARIABLES = JSON.parse(File.read(APP_ROOT.join(CONFIG['paths']['brandable_variables_json']))).freeze
Create predeploy rake task to handle Theme Editor closes: CNVS-21990 This is the rake task we call from a job server once that has new code before restarting all the app servers. It will make sure that our s3 bucket has all static assets including the css for custom themes people have created in the Theme Editor test plan: * make sure you have an config/canvas_cdn.yml file * `rm -rf public/dist` * run `bundle exec rake brand_configs:generate_and_upload_all` * in log/development.log you should see it write a _variables.scss file for each brand_config in any shard to disk, compile the css for each of those brands and push all the js/css/images/etc to s3 * browse pages in canvas, the css/images/js should be served from your "host:" configured in canvas_cdn.yml and none should 404 this change also includes: better error message when brandable_css manifest doesn't exist if the manifest file can't be found, this will tell you the full path to the file it was looking for so that if it can't find the manifest file,it will tell you the path to the file it was looking for. test plan: with RAILS_ENV=production: * rm -rf public/dist * try to access a page the error that it give you should tell you the full path to the json file it tried to read. if we haven't loaded rails yet, we still want to look at RAILS_ENV to get which style of css to generate Change-Id: I2dbb12541d6a28e90a326a51f0cddb90f313842f Reviewed-on: https://gerrit.instructure.com/58809 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-07-20 23:49:03 +08:00
use_compressed = (defined?(Rails) && Rails.env.production?) || (ENV['RAILS_ENV'] == 'production')
SASS_STYLE = ENV['SASS_STYLE'] || ((use_compressed ? 'compressed' : 'nested')).freeze
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
translate brandable css variable names test plan: * theme editor variable names, group names and helper text should all be lolcalized closes #CNVS-23768 Change-Id: I01846a0c0354342cc5593d6ac153f117ccc39b64 Reviewed-on: https://gerrit.instructure.com/65809 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: Clare Strong <clare@instructure.com> Product-Review: James Williams <jamesw@instructure.com>
2015-10-26 22:59:25 +08:00
VARIABLE_HUMAN_NAMES = {
"ic-brand-primary" => lambda { I18n.t("Primary Color") },
"ic-brand-button--primary-bgd" => lambda { I18n.t("Primary Button") },
"ic-brand-button--primary-text" => lambda { I18n.t("Primary Button Text") },
"ic-brand-button--secondary-bgd" => lambda { I18n.t("Secondary Button") },
"ic-brand-button--secondary-text" => lambda { I18n.t("Secondary Button Text") },
"ic-link-color" => lambda { I18n.t("Link") },
"ic-brand-global-nav-bgd" => lambda { I18n.t("Nav Background") },
"ic-brand-global-nav-ic-icon-svg-fill" => lambda { I18n.t("Nav Icon") },
"ic-brand-global-nav-ic-icon-svg-fill--active" => lambda { I18n.t("Nav Icon Active") },
"ic-brand-global-nav-menu-item__text-color" => lambda { I18n.t("Nav Text") },
"ic-brand-global-nav-menu-item__text-color--active" => lambda { I18n.t("Nav Text Active") },
"ic-brand-global-nav-avatar-border" => lambda { I18n.t("Nav Avatar Border") },
"ic-brand-global-nav-menu-item__badge-bgd" => lambda { I18n.t("Nav Badge") },
"ic-brand-global-nav-logo-bgd" => lambda { I18n.t("Nav Logo Background") },
"ic-brand-header-image" => lambda { I18n.t("Nav Logo") },
"ic-brand-watermark" => lambda { I18n.t("Watermark") },
"ic-brand-watermark-opacity" => lambda { I18n.t("Watermark Opacity") },
"ic-brand-favicon" => lambda { I18n.t("Favicon") },
"ic-brand-apple-touch-icon" => lambda { I18n.t("Mobile Homescreen Icon") },
"ic-brand-msapplication-tile-color" => lambda { I18n.t("Windows Tile Color") },
"ic-brand-msapplication-tile-square" => lambda { I18n.t("Windows Tile: Square") },
"ic-brand-msapplication-tile-wide" => lambda { I18n.t("Windows Tile: Wide") },
"ic-brand-right-sidebar-logo" => lambda { I18n.t("Right Sidebar Logo") },
"ic-brand-Login-body-bgd-color" => lambda { I18n.t("Background Color") },
"ic-brand-Login-body-bgd-image" => lambda { I18n.t("Background Image") },
"ic-brand-Login-body-bgd-shadow-color" => lambda { I18n.t("Body Shadow") },
"ic-brand-Login-logo" => lambda { I18n.t("Login Logo") },
"ic-brand-Login-Content-bgd-color" => lambda { I18n.t("Top Box Background") },
"ic-brand-Login-Content-border-color" => lambda { I18n.t("Top Box Border") },
"ic-brand-Login-Content-inner-bgd" => lambda { I18n.t("Inner Box Background") },
"ic-brand-Login-Content-inner-border" => lambda { I18n.t("Inner Box Border") },
"ic-brand-Login-Content-inner-body-bgd" => lambda { I18n.t("Form Background") },
"ic-brand-Login-Content-inner-body-border" => lambda { I18n.t("Form Border") },
"ic-brand-Login-Content-label-text-color" => lambda { I18n.t("Login Label") },
"ic-brand-Login-Content-password-text-color" => lambda { I18n.t("Login Link Color") },
"ic-brand-Login-Content-button-bgd" => lambda { I18n.t("Login Button") },
"ic-brand-Login-Content-button-text" => lambda { I18n.t("Login Button Text") },
"ic-brand-Login-footer-link-color" => lambda { I18n.t("Login Footer Link") },
"ic-brand-Login-footer-link-color-hover" => lambda { I18n.t("Login Footer Link Hover") },
"ic-brand-Login-instructure-logo" => lambda { I18n.t("Login Instructure Logo") }
}.freeze
GROUP_NAMES = {
"global_branding" => lambda { I18n.t("Global Branding") },
"global_navigation" => lambda { I18n.t("Global Navigation") },
"watermarks" => lambda { I18n.t("Watermarks & Other Images") },
"login" => lambda { I18n.t("Login Screen") }
}.freeze
HELPER_TEXTS = {
"ic-brand-header-image" => lambda { I18n.t("Accepted formats: svg, png, jpg, gif") },
"ic-brand-watermark" => lambda { I18n.t("This image appears as a background watermark to your page. Accepted formats: png, svg, gif, jpeg") },
"ic-brand-watermark-opacity" => lambda { I18n.t("Specify the transparency of the watermark background image.") },
"ic-brand-favicon" => lambda { I18n.t("You can use a single 16x16, 32x32, 48x48 ico file.") },
"ic-brand-apple-touch-icon" => lambda { I18n.t("The shortcut icon for iOS/Android devices. 180x180 png") },
"ic-brand-msapplication-tile-square" => lambda { I18n.t("558x558 png, jpg, gif (1.8x the standard tile size, so it can be scaled up or down as needed)") },
"ic-brand-msapplication-tile-wide" => lambda { I18n.t("558x270 png, jpg, gif") },
"ic-brand-right-sidebar-logo" => lambda { I18n.t("A full-size logo that appears in the right sidebar on the Canvas dashboard. Ideal size is 360 x 140 pixels. Accepted formats: svg, png, jpeg, gif") },
"ic-brand-Login-body-bgd-shadow-color" => lambda { I18n.t("accepted formats: hex, rgba, rgb, hsl") }
}.freeze
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
class << self
def variables_map
@variables_map ||= BRANDABLE_VARIABLES.each_with_object({}) do |variable_group, memo|
variable_group['variables'].each { |variable| memo[variable['variable_name']] = variable }
end.freeze
end
# gets the *effective* value for a brandable variable
def brand_variable_value(variable_name, active_brand_config=nil)
explicit_value = active_brand_config && active_brand_config.get_value(variable_name).presence
return explicit_value if explicit_value
config = variables_map[variable_name]
default = config['default']
return brand_variable_value(default[1..-1], active_brand_config) if default && default.starts_with?('$')
# while in our sass, we want `url(/images/foo.png)`,
# the Rails Asset Helpers expect us to not have the '/images/', eg: <%= image_tag('foo.png') %>
ThemeEditor: fix 404 to default preview images fixes: CNVS-22258 test plan: * open theme editor and open the "watermarks and other images section. you should not see any 404's in the browser console and you should see a default for each except for the 'watermark' * in IE, make sure you don't see a "broken link" image for the watermark Change-Id: Iea743e8efc5115e2f4dfae6b8d12f26d4f3f346f Reviewed-on: https://gerrit.instructure.com/59793 Reviewed-by: Jacob Fugal <jacob@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-08-01 06:38:28 +08:00
default = default.sub(/^\/images\//, '') if config['type'] == 'image'
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
default
end
don't blow away the brandConfig someone else is working on closes: CNVS-21804 this will also do a better job of cleaning up the app/stylesheets/brandable_css_brands dir (so when you compile sass, it won't do stuff for brandConfigs that aren't being used anymore) test plan: open theme editor, make some changes, hit preview. as a different user in a different browser, open theme editor, make changes, press save. now in the first window, try to hit save. before it would break, now it will work Change-Id: I094f737d35c854764a7c361bec4798b8a2203410 Reviewed-on: https://gerrit.instructure.com/58102 Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Product-Review: Jennifer Stern <jstern@instructure.com> Tested-by: Jenkins QA-Review: Nathan Rogowski <nathan@instructure.com>
2015-07-10 05:02:27 +08:00
def branded_scss_folder
Pathname.new(CONFIG['paths']['branded_scss_folder'])
end
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
def variants
@variants ||= CONFIG['variants'].map{|(k)| k }.freeze
end
def brandable_variants
@brandable_variants ||= CONFIG['variants'].select{|_, v| v['brandable']}.map{ |k,_| k }.freeze
end
def combined_checksums
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
if defined?(ActionController) && ActionController::Base.perform_caching && defined?(@combined_checksums)
return @combined_checksums
end
file = APP_ROOT.join(CONFIG['paths']['bundles_with_deps'] + SASS_STYLE)
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
if file.exist?
@combined_checksums = JSON.parse(file.read).each_with_object({}) do |(k, v), memo|
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
memo[k] = v.symbolize_keys.slice(:combinedChecksum, :includesNoVariables)
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
end.freeze
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
elsif defined?(Rails) && Rails.env.production?
Create predeploy rake task to handle Theme Editor closes: CNVS-21990 This is the rake task we call from a job server once that has new code before restarting all the app servers. It will make sure that our s3 bucket has all static assets including the css for custom themes people have created in the Theme Editor test plan: * make sure you have an config/canvas_cdn.yml file * `rm -rf public/dist` * run `bundle exec rake brand_configs:generate_and_upload_all` * in log/development.log you should see it write a _variables.scss file for each brand_config in any shard to disk, compile the css for each of those brands and push all the js/css/images/etc to s3 * browse pages in canvas, the css/images/js should be served from your "host:" configured in canvas_cdn.yml and none should 404 this change also includes: better error message when brandable_css manifest doesn't exist if the manifest file can't be found, this will tell you the full path to the file it was looking for so that if it can't find the manifest file,it will tell you the path to the file it was looking for. test plan: with RAILS_ENV=production: * rm -rf public/dist * try to access a page the error that it give you should tell you the full path to the json file it tried to read. if we haven't loaded rails yet, we still want to look at RAILS_ENV to get which style of css to generate Change-Id: I2dbb12541d6a28e90a326a51f0cddb90f313842f Reviewed-on: https://gerrit.instructure.com/58809 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-07-20 23:49:03 +08:00
raise "#{file.expand_path} does not exist. You need to run #{cli} before you can serve css."
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
else
# for dev/test there might be cases where you don't want it to raise an exception
# if you haven't ran `brandable_css` and the manifest file doesn't exist yet.
# eg: you want to test a controller action and you don't care that it links
# to a css file that hasn't been created yet.
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
default_value = {combinedChecksum: "Error: unknown css checksum. you need to run #{cli}"}.freeze
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
@combined_checksums = Hash.new(default_value).freeze
end
end
# bundle path should be something like "bundles/speedgrader" or "plugins/analytics/something"
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
def cache_for(bundle_path, variant)
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
key = ["#{bundle_path}.scss", variant].join(CONFIG['manifest_key_seperator'])
fingerprint = combined_checksums[key]
raise "Fingerprint not found. #{bundle_path} #{variant}" unless fingerprint
fingerprint
end
def all_fingerprints_for(bundle_path)
variants.each_with_object({}) do |variant, object|
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
object[variant] = cache_for(bundle_path, variant)
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
end
end
def cli
'./node_modules/.bin/brandable_css'
end
def compile_all!
run_cli!
end
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
def compile_brand!(brand_id, opts=nil)
run_cli!('--brand-id', brand_id, opts)
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
end
private
def run_cli!(*args)
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
opts = args.extract_options!
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
# this makes sure the symlinks to app/stylesheets/plugins/analytics, etc exist
# so their scss files can be picked up and compiled with everything else
require 'config/initializers/plugin_symlinks'
don't proceed like normal if brandable_css cmd fails fixes: CNVS-23632 it turns out, the way I was doing this ruby would create a sh subprocess and brandable_css would be it's subprocess. so $? would be the sh process (which would always exit successfully). test plan: * in theme editor, try to preview a theme * but before you do, do something to make it so brandable_css will fail (like uninstall node or rm -rf node_modules or use activity monitor to view active processes and kill brandable_css when it appears) * it should say "something went wrong generating..." instead of continuing like everything worked Change-Id: I3c80c18381bb52c71d4b79d5b151988d6cf5cc3b Reviewed-on: https://gerrit.instructure.com/63948 Reviewed-by: Jacob Fugal <jacob@instructure.com> Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-09-25 01:37:49 +08:00
command = [cli].push(*args).shelljoin
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
msg = "running BrandableCSS CLI: #{command}"
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
Rails.logger.try(:debug, msg) if defined?(Rails)
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
percent_complete = 0
don't proceed like normal if brandable_css cmd fails fixes: CNVS-23632 it turns out, the way I was doing this ruby would create a sh subprocess and brandable_css would be it's subprocess. so $? would be the sh process (which would always exit successfully). test plan: * in theme editor, try to preview a theme * but before you do, do something to make it so brandable_css will fail (like uninstall node or rm -rf node_modules or use activity monitor to view active processes and kill brandable_css when it appears) * it should say "something went wrong generating..." instead of continuing like everything worked Change-Id: I3c80c18381bb52c71d4b79d5b151988d6cf5cc3b Reviewed-on: https://gerrit.instructure.com/63948 Reviewed-by: Jacob Fugal <jacob@instructure.com> Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-09-25 01:37:49 +08:00
Open3.popen2e(command) do |_stdin, stdout_and_stderr, wait_thr|
stdout_and_stderr.each do |line|
puts line.chomp!
# This is a good-enough-for-now approximation to show the progress
# bar in the UI. Since we don't know exactly how many files there are,
# it will progress towards 100% but never quite hit it until it is complete.
# Each tick it will cut 4% of the remaining percentage. Meaning it will look like
# it goes fast at first but then slows down, but will always keep moving.
if opts && opts[:on_progress] && line.starts_with?('compiled ')
percent_complete += (100.0 - percent_complete) * 0.04
opts[:on_progress].call(percent_complete)
end
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
end
don't proceed like normal if brandable_css cmd fails fixes: CNVS-23632 it turns out, the way I was doing this ruby would create a sh subprocess and brandable_css would be it's subprocess. so $? would be the sh process (which would always exit successfully). test plan: * in theme editor, try to preview a theme * but before you do, do something to make it so brandable_css will fail (like uninstall node or rm -rf node_modules or use activity monitor to view active processes and kill brandable_css when it appears) * it should say "something went wrong generating..." instead of continuing like everything worked Change-Id: I3c80c18381bb52c71d4b79d5b151988d6cf5cc3b Reviewed-on: https://gerrit.instructure.com/63948 Reviewed-by: Jacob Fugal <jacob@instructure.com> Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-09-25 01:37:49 +08:00
raise("Error #{msg}") unless wait_thr.value.success?
upload css direct to s3 and optimize unbranded css 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>
2015-08-21 07:13:25 +08:00
end
A new way of doing css/sass & New Canvas Theme Editor 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>
2015-02-12 03:51:05 +08:00
end
end
end