This patchset enables generating Canvas API documentation
in Markdown format. The goal of the work is to be able to import
the whole Canvas API documentation into the new Documentation Portal
(developerdocs.instructure.com).
refs: https://instructure.atlassian.net/browse/SAS-3699
How to generate the docs in Markdown format?
Run this command from a Canvas box:
`OUTPUT_FORMAT=markdown rake doc:api`
The generated documentation will be available in `public/doc/api_md`.
test-plan:
- Backward compatibility: I regenerated the documentation in HTML format
and compared each file with the output from an original documentation.
Only the timestamps in the footer differed; everything else was the same.
- Content parity: I compared the content of each generated Markdown file
with its "twin brother" HTML file. While there are differences in look and
feel, the content is consistent. This is how it looks like in Markdown
format:
https://inst.gitbook.io/sandbox-instructure-developer-portal/0hk9uatQ63bsQYSzZzF2/
Note:
The change does not influence in any way the HTML formatted
Canvas Documentation or the way is generated.
Change-Id: If4f11a35e7cea77f434faa3c699937a11fa24d51
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/357227
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Jozsef Kercso <jozsef.kercso@instructure.com>
refs VICE-4186
flag=instui_nav
Test plan:
- Enable instui_nav FF
- Go to Announcements page
- Note that header is compatible with ICE design
Change-Id: I2cf2cb0eb55c478c093ce64b6920b78af051a121
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/346960
Reviewed-by: Roland Beres <roland.beres@instructure.com>
Reviewed-by: Mario Hegyi <mario.hegyi@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Mario Hegyi <mario.hegyi@instructure.com>
Product-Review: Roland Beres <roland.beres@instructure.com>
you'll put certificates in there that should not be committed.
the few files that _should_ be committed (InCommon and UK Federation
metadata) can be force-added
Change-Id: Ibfd0c9ae6804afb2b3ae2c259aa654c6ea9fd883
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/344837
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
It's the new default debugger in ruby 3.1. Rails switched to it in 7.0,
avoids issues with Zeitwerk, has a more modern interface based on
current IRB, supports Unix Domain Sockets for remote debugging,
promises even better future maintenance due to being part of Ruby,
etc.
Change-Id: Ieaa7872f1c0308b16ae180fdb16df5dd6caa87a8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/328241
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
Build-Review: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
closes AE-283
this eliminates script/sync_lockfiles.rb and integrates its
functionality directly into `bundle install`, `bundle check`, etc.
it also generalizes a few pieces so that the same approach is used
for all use cases:
* syncing versions between the main Gemfile and gems in gems/
* maintaining separate lockfiles for no plugins/including
private plugins
* maintaining separate lockfiles for multiple Rails versions
(crossed with the previous bullet)
The differences between them are just small variations on how strict
versions must match between lockfiles, and requiring pinning of
versions not in the default lockfile.
For full details, checks the docs on BundlerLockfileExtensions
This does change the strategy for filtering private plugin dependencies
out of the committed lockfile(s) - instead of filtering based on hash
of source, simply don't even include private plugin gems in the gemfile
when building the filtered lockfile (i.e. dynamic Gemfile, rather than
monkeypatching bundler to filter out -- semi-succesfully -- private
plugins from the Definition).
It also changes the "default" lockfile for Canvas that gets checked
in to be Gemfile.lock, so that other tools that are not
multi-lockfile aware can find it (such as rubocop, dependabot, and
others). This will be the lockfile corresponding to the current
default rails version for Canvas, and without private plugins.
Change-Id: I7ba398381974acbc4445f34fa3b788e8a07c5ce6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/317888
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Build-Review: Cody Cutrer <cody@instructure.com>
still need to ensure gem dependencies are consistent, but this should
prevent unexpected breakage during tests
Change-Id: I39420479fd3fe4f7e49a12a418eca033fcdc7564
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/314979
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Build-Review: Cody Cutrer <cody@instructure.com>
This adds 88 ignores and removes 32, and with more careful review
we could probably shrink the ignore list, but this will allow
brakeman to become more manageable/useable and therefore actually
useful
Change-Id: I65514b4fe5fa046560a92415db0b3d3403aa20f3
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/315511
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
add the inst-cli config files used when setting up canvas with inst-cli.
Test Plan:
QA to be done on https://gerrit.instructure.com/c/inst-cli/+/314462
Change-Id: Ice2324d994641f59b7c26332c77e403af015a1cd
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/314463
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
QA-Review: Andrea Cirulli <andrea.cirulli@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
refs FOO-2801
flag = none
[change-merged][build-registry-path=jenkins/canvas-lms/foo-2801]
[pin-commit-analytics=4fd9e2fbb7fc2790ba7985bb4025e901bf33a9e3]
this part reaches the goal of this series where we turn the locale
files that are used by our JS engine into plain JSON files that don't
need any special processing and are also of a simpler structure
before, translations were stored in a tree structure that we needed to
traverse in order to look up a translation, which we did by
deconstructing keys through the "." operator:
I18n.lookup("foo.bar.baz")
{
en: {
foo: {
bar: {
baz: "Hello!" // <-- this
}
}
}
}
now, translations are stored in a flat dictionary structure where the
keys are not processed in any special way but are instead "fully
qualified":
I18n.lookup("foo.bar.baz")
{
en: {
"foo.bar.baz": "Hello!"
}
}
this is nice when you consider that the previous structure contained a
mixture of nested keys and flat ones, based on different conditions:
{
en: {
"asdf_1234": "ASDF", // inferred, so it was never "nested"
"foo": {
"bar": {
"baz": {
"one": "One banana",
"other": "Many many bananas"
}
}
}
}
}
because, for example, keys that are inferred by i18nliner end up at
the root level and not nested. You also never knew whether a key was a
container or a phrase that was pluralized, because they both had the
shape of an object.
Now these distinctions are gone; a key is always fully-qualified
regardless of how it was specified:
1) inferred: I18n.t("Inferred key")
// => inferred_key_c49e3743
2) absolute: I18n.t('#buttons.cancel')
// => buttons.cancel
3) relative: I18n = useScope('outer')
I18n.t('something', 'Something')
// => outer.something
4) nested: I18n = useScope('outer');
I18n.t('something.inside', 'Something inside')
// => outer.something.inside
5) pluralized: I18n.t({
one: 'One banana',
other: 'Many bananas'
})
// => many_many_bananas_ce8e7fb7.one
// => many_many_bananas_ce8e7fb7.other
Change-Id: I7c33fbd2321d7d56994223d65f2572db0ac12ed5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293675
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2835
flag = none
because instui no longer maintains that library and now we need to
adjust its code
only planner and RCE are its users, but it doesn't need to be published
to npm because it's only used during build
Change-Id: I96db84e71cac53556842e094c780d89519aed769
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294192
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jon Scheiding <jon.scheiding@instructure.com>
QA-Review: Jon Scheiding <jon.scheiding@instructure.com>
Product-Review: Jon Scheiding <jon.scheiding@instructure.com>
Change-Id: I61d5ba9f6ef5e0837da2ec22b695b9a56b88acb5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293104
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: August Thornton <august@instructure.com>
Reviewed-by: Alex Slaughter <aslaughter@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
refs DE-523
Previously, the current version would be represented by Gemfile.lock and the next version by Gemfile.lock.next. Replace both with a common format of Gemfile.rails<version>.lock to be able to iterate over the files in a cleaner way.
Change-Id: I35aef3a14e726eb35db8aebc808af4a925552c01
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/288563
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
refs DE-523
Test Plan
1. Ensure CANVAS_RAILS override works
2. Ensure file override works
3. Ensure consul override works
Change-Id: I6eea63bba5c401428c02179a3d6187c8265ce33e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/287849
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
- vendor/ is now unused except for vendor/qti_migration_tool
so ignore it entirely instead of just vendor/gems and vendor/cache
- local sqlite database haven't been used in like nine years
- ignore the redis dump too
Change-Id: Ideb9e3f9d89e90ffa1bd5408b9f95809b5e10047
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/285545
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Mysti Lilla <mysti@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
refs FOO-2720
refs DE-1022
Currently, translations are compiled on a per-scope level. The primary problem by doing this is that each generated scope file contains the translations for all languages, leading users to needing to download translations for languages they will never use.
Instead, we now generate a single translations file per language. This file is loaded and cached by the browser at the beginning of page load.
[change-merged]
[build-registry-path=jenkins/canvas-lms/de-1022]
Change-Id: I64b0d054b04e3d81bb7263650481d1d3fe9a4868
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284285
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
Also moves config/initializer/crystalball.rb to spec/support
to prevent it from running in prod
This reverts commit 9a9c68be6e.
Test-plan:
- passes cd to edge without failure
- generates map successfully in PoC build
Change-Id: I67c02ebaea06e11b3a3721aa49217da16e75bd32
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/279848
Reviewed-by: Michael Hargiss <mhargiss@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
This reverts commit bd847c2d14.
Reason for revert: breaking cd
Change-Id: I85ed1dc69045d2cd984778da12c2e0b402b842ad
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/279637
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
flag=none
Test-plan:
- #crystalball-noisy should link to the latest build AND the
latest map should be linked (stored as a build artifact)
- job should run nightly
- nightly alerts should promopt #crystalball-noisy posts
(but not gerrit manual triggers)
Change-Id: Ibbd45dfd8a9b3ed8f4c662b322214cbbc3dc99b4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/277205
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Michael Hargiss <mhargiss@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
refs FOO-2280
flag = none
monitor the use of date-picker widgets to learn more about the use of
the free-form/natural parsing feature.
I've opted to track the events at the innermost layer (DatetimeField
and DateInput) and shove them onto a localStorage buffer that gets
posted to the (TBD) backend on the subsequent page load. This feels like
a simple approach with downsides that we can live with.
The buffer is capped at 50 events, and each event will truncate values
that are longer than 32 characters. There's an ID attached to each event
that points to the widget it came from, which we can use to group
related events to analyze the larger interaction.
:: test plan ::
first, we test the monitoring of the jQuery widget. Create an assignment
and go to its edit page. Scroll down to the "Assign" section as we'll be
spending our time with the date fields there.
- type something like "aug 17" into a date field like Due
- wait for a second and verify the buffer gets filled with a new event
of method "type" (run this or just look at ur localStorage):
console.log(
JSON.stringify(
JSON.parse(
localStorage.getItem('dtnpi')
), null, 4
)
)
- now, pick a date from the Picker widget
- wait for a second and verify the event this time is of the
method "pick"
- now, paste some value into the field and verify the new event is of
method "paste" and that "value" actually points to the PASTED VALUE
and not to whatever the widget ended up translating it to
at this point, we will exercise the same steps but for the React
<DateInput /> widget. Go to the course Assignments page and click on
"..." then "Edit Assignment Dates". You will see many date fields, any
of them will suffice:
- verify typing generates the expected event
- verify picking generates the expected event
- verify pasting generates the expected event
Change-Id: I1f3a4e82a62fb19487516a324dcb0ea34236725e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/272364
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: August Thornton <august@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
closes INTEROP-6689
flag=none
also dev config for api-gateway development
TEST PLAN:
1) provide api gateway url through dynamic settings
2) notification preferences uses api gateway for graphql
queries
Change-Id: I78c59998d6de522df4f16a98d8f468424add674c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/271525
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
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>
fixes FOO-1824
flag = none
[pin-commit-analytics=7f2f049830a11e43f4a5d0031e3c4ecc3145ccdb]
[pin-commit-instructure_misc_plugin=9b505159130c0724ce6bcbb75d07d40ff16a1961]
read directly from gems/plugins/* instead of symlinks
- dropped dead brandable_css config property "all_sass_files"
- webpack test runner now generates a file that runs all plugin spec
files (from spec_canvas/coffeescripts)
test plan: you can remove your symlinks and still survive!
Change-Id: I0206c2d827aa9f59b0374b21f0863443dff3be0f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262346
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
flag = none
closes: DE-529
Test Plan:
Test All On Linux and Mac
-docker_dev_setup without mutagen
-test with dinghy not created, down, missing
-docker_dev_setup with mutagen
-with docker desktop not running
-with and without dory
-docker_dev_update with and without mutagen
-with update-code option and without
-update_canvas for local is not broken
-following Next Steps, all works for mutagen
Change-Id: I7690dc2d919cf1b9d8af86200ec8439da9135d16
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262293
QA-Review: James Butters <jbutters@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
This reverts commit 8704d83a37.
Reason for revert: Vault is not ready for prime time
Change-Id: I37c41be5345aa2ee362df4e7831cf64d2729668d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/261952
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Evan Battaglia <ebattaglia@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Test plan:
- From a rails console, run:
MicrosoftSync::GraphService.new('ourtenant').list_education_classes
- There should be an error telling you where to put the creds
- Follow the instructions, hopefully they are self-explanatory.
- Run again and and the education classes should be listed
Change-Id: I4a8cf6f788178345bac375b8be6aa31b04bc4a24
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262423
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Single dynamo table for all release notes data. Should support active-record
style patterns (mostly) for CRUD operations, plus querying the latest N visible
records by role and environment. Also supports paginated listing of *all* notes
for administrative purposes
fixes FOO-1752
Change-Id: Ic1e7e204e93e263479a738af18daf312c801269c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/261548
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
refs DE-496
flag = none
The pattern dir/ excludes a directory named dir and (implicitly)
everything under it. With dir/, Git will never look at anything
under dir, and thus will never apply any of the “un-exclude”
patterns to anything under dir.
The pattern dir/* says nothing about dir itself; it just excludes
everything under dir. With dir/*, Git will process the direct
contents of dir, giving other patterns a chance to “un-exclude”
some bit of the content (!dir/sub/).
Test plan:
• Adding a new file under /gems/plugins/account_reports/
gets picked up by Git version control as an unstaged change
Change-Id: I5e2e04426f224032301594237a67887e005b1285
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/259440
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
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>
fixes FOO-1409
flag = none
no more client_apps, canvas_quizzes now lives as part of canvas-lms
proper inside app/jsx/, which makes the build leaner and leaves us with
one less thing to reason about
logical changes:
- converted from AMD to ES modules
- upgraded to recent react + react-router
- dropped RSVP in favor of native Promises
- used CanvasModal instead of home-grown Dialog
- removed dead code; notifications in particular were fishy as there had
no dependents at all and did not even show up in the graph
- ported tests to Jest, added more unit ones and two integration ones
- removed "config.onError" and now throws errors where appropriate
- disabled console statements in non-dev
:: test plan ::
- create a (old-school) quiz containing all types of questions
- as 3 distinct students, take the quiz and try to randomize your
answers
at this point it's helpful to have a reference to compare the screens; I
replicated the quiz on my production sandbox for this
- go to /courses/:id/quizzes/:id/submissions/:id/log
- verify it looks OK
- click on a specific question in the stream and verify the question
inspector widget works OK
- go back to stream and push "View table"
- verify the table and its controls are OK
- go to /courses/:id/quizzes/:id/statistics
- verify it looks OK
- click on ? in the discrimination index chart and verify it displays
a dialog with help content
- click on "X respondents" in one of the charts and verify it displays
a dialog with the respondent names
- verify the interactive charts do interact as expected (no logic
changed here so just a quick glance)
- link to "View in SpeedGrader" for essay-like questions works
Change-Id: I79af5ff4f1479503b5e2528b613255dde5bc45d3
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/256118
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
This story contains work to move Canvas Inbox and Storybook to `app/jsx` inside our Monolith. Storybook should now be enabled for all of `app/jsx` and works with our existing I18n code after updating webpack to load translations correctly.
Test Plan
1. Install node modules with `yarn`
2. At Canvas-LMS root, run `yarn storybook`
3. Storybook should open, test that Canvas Inbox components work as expected
Change-Id: Iccd2b103164a2da4e37b5746f4d9d2b5faf5f29d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/253024
QA-Review: Davis Hyer <dhyer@instructure.com>
Product-Review: Davis Hyer <dhyer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Davis Hyer <dhyer@instructure.com>
refs DE-324
Some tests require lib/api_scope_mapper.rb to be generated by the doc:api task, and this is a slow operation that all builds run before starting tests. Generated changes to this file are relatively rare, so let’s require developers to commit their changes to it to save time on all builds. In addition, install a linter to verify that matching changes are pushed.
[change-merged]
[build-registry-path=jenkins/canvas-lms/evaluate-webpack-docs]
Change-Id: Iaa6ebb1ba8cbb008191f6bee14b3bf2f413168e7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/250801
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Ryan Norton <rnorton@instructure.com>
Using the parallel_tests gem allows us to parallelize more
and a bit simpler. Removes headless stuff now that we don't
use it anymore, comments out video recording code since it
doesn't work, removes all knapsack code.
flag = none
Test Plan:
Jenkins rspec and selenium builds pass
rspec and selenium builds copy results to html publisher
rspec and selenium have nodes split into processes
Change-Id: Ibd00eba77f8193be5eadd41aef1e0617c9ae470c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/227677
Reviewed-by: Jacob Powell <spowell@instructure.com>
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
This will fix some issues with jenkins builds failing if the
patchset is behind some newer graphql changes, as well as allowing
us to include content defined in our plugins in the graphql.schema
file.
Test Plan:
- Jenkins passes
fixes USERS-210
flag = none
Change-Id: Ic44849ee57955e0b90395661a66f6d5840a38e87
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/222029
Reviewed-by: Rex Fleischer <rfleischer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Steve Shepherd <sshepherd@instructure.com>
Product-Review: Landon Gilbert-Bland <lbland@instructure.com>
This is in an attempt to
1. Prevent unpredictable behavior when
running docker-compose without specifying
docker-compose files (intentionally or
unintentionally *This is exactly a problem
I found that caused issues, running the defaults on accident)
2. Follow more closely what other projects
are doing, they don’t have the override committed
3. Follow typical industry standard,
from what I’ve seen, such as
https://blog.sentry.io/2019/02/28/exception-perceptions-docker
test plan:
Running ./script/docker_dev_setup.sh with no
docker-compose.override.yml
in the root directory will print the message
"Copying default configuration from
docker-compose.override.yml.example to
docker-compose.override.yml" and copy the file in.
Running ./script/docker_dev_setup.sh with an existing
docker-compose.override.yml will simply print
"docker-compose.override.yml exists, skipping
copy of default configuration"
Also check that the documentation changes
sufficiently explain the new
process and what to expect.
The file shouldn't be in the root of the
directory in the repo anymore,
in order to prevent unwanted default behavior
(requires explicit naming
of docker-compose files)
There should be a
docker-compose.override.yml.example in the config
folder for reference.
• Add `docker-compose.override.yml` to `.gitignore`
• Leave a copy of the current
`docker-compose.override.yml` in
`config/docker-compose.override.yml.example`
• Delete `docker-compose.override.yml`
from the root directory
fixes CORE-3409
Change-Id: I9cffeb52f2cc233061f78de10fcb240c09743542
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/214116
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Jenkins
Reviewed-by: Robert Lamb <rlamb@instructure.com>
QA-Review: S. Jacob Powell <spowell@instructure.com>
Product-Review: S. Jacob Powell <spowell@instructure.com>
Jozsef Kercso