canvas-lms/.gitignore

94 lines
1.8 KiB
Plaintext
Raw Normal View History

# What goes in this file:
# * local canvas configuration (db, ymls, overrides, etc.)
# * generated/cached stuff (docs, css, js, uploads, etc.)
#
# What does NOT go in this file
# * editor-related stuff
# * random scripts only used by you
# * env-specific stuff (e.g. .DS_Store)
# * pretty much any dotfile not already covered (e.g. .rvmrc)
#
# That's what .git/info/exclude and core.excludesfile are for :)
.bundle/
.byebug_history
.env
.mutagen
/.yardoc/
/.ruby-version
/app/views/info/styleguide.html.erb
/config/*.yml
InstID tokens, part 1: generation fixes INTEROP-6913, INTEROP-6892, INTEROP-6893, INTEROP-6920 flag = none This commit introduces the InstID token, a signed and encrypted JWT (aka JWE) that will soon be usable for Canvas API access (that's "part 2"). If the InstID class is configured with a private signing key and public encryption key, it will be able to produce encrypted JWTs and validate and deserialize decrypted JWTs. If it is configured with only a public signing key, it cannot produce tokens but it can still validate and deserialize decrypted ones. Therefore this class can be used by the identity provider (currently Canvas) to produce tokens, but also by any services that want to use InstID tokens for authentication. test plan: 1) generate two RSA keypairs. one way to generate a keypair is from a rails console: > keypair = Canvas::Security::RSAKeyPair.new > puts keypair.private_key.to_s > puts keypair.public_key.to_s 2) choose which one is for signing and which is for encryption, then add the private signing key and the public encryption key to your rails credentials: - run `bin/rails credentials:edit` - add an entry like the following, and then save and close your editor: ``` inst_id: encryption_key: | -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvY1EMlGm1daM87ejGuFX <...snip...> /wIDAQAB -----END PUBLIC KEY----- signing_key: | -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAnDwED/QOB0f0H6TOZqLmjaPqA7m8c40NDXkAa6u5cK8zCbk3 <...snip...> QhjPgifBwTrzj21484CfiPfy5oe756Exerj8PIlRrE/hxWRSDwBIOg== -----END RSA PRIVATE KEY----- ``` 3) open a rails console and do: > id = InstID.for_user('user-uuid') > id.to_token # make sure this doesn't blow up > token = id.to_unencrypted_token > decoded_id = InstID.from_token(token) > id.jwt_payload == decoded_id.jwt_payload # => true TODO in followup commits: - make canvas accept InstID tokens for auth Change-Id: Ie550c17507c26f9944bd62a747a6a63161e8e770 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/268872 Reviewed-by: Ethan Vizitei <evizitei@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> QA-Review: Michael Ziwisky <mziwisky@instructure.com> Product-Review: Michael Ziwisky <mziwisky@instructure.com>
2021-07-13 11:46:17 +08:00
/config/credentials.yml.enc
!/config/credentials.test.yml
/config/environments/*-local.rb
/config/locales/generated/
/config/RAILS6_1
/coverage/
/coverage-js/
/db/schema.rb
/db/*.sqlite*
/db/*sql
Add docker-compose.override.yml to .gitignore This is in an attempt to 1. Prevent unpredictable behavior when running docker-compose without specifying docker-compose files (intentionally or unintentionally *This is exactly a problem I found that caused issues, running the defaults on accident) 2. Follow more closely what other projects are doing, they don’t have the override committed 3. Follow typical industry standard, from what I’ve seen, such as https://blog.sentry.io/2019/02/28/exception-perceptions-docker test plan: Running ./script/docker_dev_setup.sh with no docker-compose.override.yml in the root directory will print the message "Copying default configuration from docker-compose.override.yml.example to docker-compose.override.yml" and copy the file in. Running ./script/docker_dev_setup.sh with an existing docker-compose.override.yml will simply print "docker-compose.override.yml exists, skipping copy of default configuration" Also check that the documentation changes sufficiently explain the new process and what to expect. The file shouldn't be in the root of the directory in the repo anymore, in order to prevent unwanted default behavior (requires explicit naming of docker-compose files) There should be a docker-compose.override.yml.example in the config folder for reference. • Add `docker-compose.override.yml` to `.gitignore` • Leave a copy of the current `docker-compose.override.yml` in `config/docker-compose.override.yml.example` • Delete `docker-compose.override.yml` from the root directory fixes CORE-3409 Change-Id: I9cffeb52f2cc233061f78de10fcb240c09743542 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/214116 Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> Tested-by: Jenkins Reviewed-by: Robert Lamb <rlamb@instructure.com> QA-Review: S. Jacob Powell <spowell@instructure.com> Product-Review: S. Jacob Powell <spowell@instructure.com>
2019-10-22 05:51:15 +08:00
docker-compose.override.yml
/exports/
Gemfile.lock
Gemfile.lock.next
/log/*
!/log/.keep
!/log/parallel-runtime-rspec.log
mkmf.log
/node_modules
npm-debug.log
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
/public/dist/
/public/doc/api/
/public/javascripts/translations/
/storybook-static/
/tmp/*
!/tmp/.keep
/vendor/bundle/
/vendor/cache/
yarn-error.log
# canvas-gems
Quiz Stats [Backend] - Gem & Essays Refactoring the generation of quiz question statistics into its own gem. This patch adds support for Essay question statistics. Closes CNVS-12725 TEST PLAN ---- ---- - create a quiz with an essay question - perform an API request to retrieve the quiz statistics - ensure that the following metrics are generated and correct: - "graded": number of students whose answers have been graded by the teacher - "full_credit": number of students who received a full score - "point_distribution": a list of scores and the number of students who received them (so if 2 students got graded for 3 points, it should have a key of 2 and a value of 3), un-graded submissions should be keyed under null - "responses": number of students who answered the question (wrote anything) - "user_ids": IDs of those students - documentation for QuizStatistics -> Essay should be updated with the new stats > Other things to test - verify that the old statistics page still renders: /courses/:course_id/quizzes/:quiz_id/statistics - verify that you can still generate both student and item analysis CSV reports API endpoint for quiz stats: /api/v1/courses/:courseid/quizzes/:quiz_id/statistics [GET] Change-Id: Ib15434ff4cef89ac211c1f4602d1ee609ef48ec4 Reviewed-on: https://gerrit.instructure.com/33990 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Caleb Guanzon <cguanzon@instructure.com> Reviewed-by: Derek DeVries <ddevries@instructure.com> Product-Review: Ahmad Amireh <ahmad@instructure.com>
2014-04-20 16:22:49 +08:00
/gems/*/coverage
/gems/*/tmp
upgrade to node 6 closes: CNVS-29725 this gets everything working on node 6. As far as our build process goes, it cannot support running on both node 6 at the same time as 0.12 since our i18nliner handlebars stuff uses jsdom and one version of it only works on node <4 and the next only works on 4+. But the stuff in the production dependencies in package.json, aka the stuff that runs on the job servers (brandable_css), can work on both. we just need to run npm rebuild on the job servers if the stuff that was npm installed into ./node_modules was compiled against a different version of node. that is done here: https://gerrit.instructure.com/81254 that commit needs to be committed to caturday before we commit and deploy this to beta as far as managing node, there are 2 "official" ways that will make you life easier, you can either just use docker or use nvm (https://github.com/creationix/nvm) if you use nvm and if you use ZSH: Put this into your $HOME/.zshrc to call nvm use automatically whenever you enter a directory that contains an .nvmrc file with a string telling nvm which node to use: # place this after nvm initialization! autoload -U add-zsh-hook load-nvmrc() { if [[ -f .nvmrc && -r .nvmrc ]]; then nvm use elif [[ $(nvm version) != $(nvm version default) ]]; then echo "Reverting to nvm default version" nvm use default fi } add-zsh-hook chpwd load-nvmrc load-nvmrc but however you do it, as long as you have node 6.2 installed it should work test plan: * install nvm * check this patchset out * run bundle exec rake canvas:compile_assets * it should work * use theme editor to preview a change to a theme * it should work Change-Id: I1cc9faed361938afc713c4b921042386b956db70 Reviewed-on: https://gerrit.instructure.com/80839 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2016-05-27 07:39:09 +08:00
/gems/*/node_modules
/gems/plugins/*
create rebase_canvas_and_plugin script create rebase_canvas_and_plugin script to improve how we handle rebasing code, and extract to a standalone script. closes: DE-496 flag = none Test Plan: -Jenskins passes -Run script, no options, no uncommitted changes, no merge conflicts -script rebases canvas and all git plugins -Run script with skip-canvas -script does not rebase or stash canvas -successfully rebases all git plugins -Run script with skip-plugins -script rebases canvas -no plugins get rebased or stashed -Run script with 'skip-plugins <name-of-plugin>' -script rebases canvas -script will rebase git plugins except for the one listed -Run script with uncommitted changes to one or more repos -script will prompt to stash changes and list the repos needing stash -Allow script to stash -script will stash then rebase those repos -Do not allow script to stash -script will exit with message saying to stash then re-run script -Run script with merge conflicts with master on any repo -script will fail to rebase that repo, but continue to rebase all other repos. -Ending message will inform of failed rebase and which repo Change-Id: Id6a6efafc38f6363e853ccda1264d39cc070cf52 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/258351 Reviewed-by: Aaron Ogata <aogata@instructure.com> Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com> Product-Review: James Butters <jbutters@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> QA-Review: Andrea Cirulli <andrea.cirulli@instructure.com>
2021-02-09 04:18:53 +08:00
!/gems/plugins/academic_benchmark/
!/gems/plugins/account_reports/
!/gems/plugins/moodle_importer/
!/gems/plugins/qti_exporter/
!/gems/plugins/respondus_soap_endpoint/
!/gems/plugins/simply_versioned/
# user docker compose overrides
docker-compose.local.*
# experimental api gateway config
docker-compose/api-gateway.override.yml
# sub-packages
/packages/*/node_modules
Fetch things sooner on the dashboard closes: CORE-2904 CORE-2905 CORE-2906 This will send the XHR requests for the dashcards and for all the stuff in the planner dashboard sooner. As in, as soon as the html document comes back from the server, instead of waiting until all the js bundles have downloaded and executed. This should remove a round-trip from the dashboard page and you should notice the planner and dashcard dashboards complete loading a lot faster. By sending the requests sooner, our app servers can work on them while the browser is downloading all the rest of the JS that it needs to run the page. And by having our app servers work on that at the same time the browser works on the JS, the entire page will complete loading faster. Test plan: * go to the planner dashboard * you should see 4 requests with the type “fetch” in the network panel in the waterfall right at the same time the html document is returned * you should not see any more XHRs sent from axios on page load for the planner dashboard (it should use the prefetched ones) * in a prod environment, where you have multiple app server processes handling requests, the planner dashboard should complete loading a lot faster * In that same prod like environment, go to the dashcard dashboard * same thing, it should issue a “fetch” request right with the html document comes back from the server and not issue an second XHR once the JS is loaded. * it should be complete loading significantly faster too. Change-Id: I0503c1a4d913fd1baa4dad22b9a88333ff747c0d Reviewed-on: https://gerrit.instructure.com/192161 Tested-by: Jenkins QA-Review: Mysti Lilla <mysti@instructure.com> Product-Review: Mysti Lilla <mysti@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
2019-05-04 14:59:37 +08:00
/packages/*/es
/packages/*/lib
/packages/*/coverage/
/packages/canvas-planner/.babel-cache
# pact artifacts
/reports/
/pacts/
# generated scopes
/lib/api_scope_mapper.rb
# generated scopes markdown
/doc/api/api_token_scopes.md
# js coverage stuff
.nyc_output
coverage-jest
coverage-karma
# generated graphql schema
schema.graphql
# Ignore master key for decrypting credentials and more.
/config/master.key