They now live in their own private repository.
Change-Id: Id4e9e3f745c1311fc75f99bb62333af44b90f145
Reviewed-on: https://gerrit.instructure.com/66125
Tested-by: Jenkins
Reviewed-by: Taylor Wilson <twilson@instructure.com>
Product-Review: Derek Hansen <dhansen@instructure.com>
QA-Review: Derek Hansen <dhansen@instructure.com>
testbot gem is now being referenced on the build machine locally and no longer relies on old github
reference to be used within Canvas
Change-Id: I4966f9afef38d6832bda7b88db125456850d7e57
Reviewed-on: https://gerrit.instructure.com/65259
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
the # is not necessary, but now you won't get misleading linter messages
if you do one, e.g. refs #PROJ-123
test plan:
1. the linter should not complain about this commit message
Change-Id: I3eb9e5de093a5b8948c2892bd3ecdec8c3ea4add
Reviewed-on: https://gerrit.instructure.com/65225
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
This includes a basic set of common methods and environment variables
to be used for both iOS and Android platforms with Appium. Includes the
inclusion of the appium_lib gem in Gemfile.d and a minor modification
to spec/spec_helper.rb to facilitate control of seeding the ID for
DeveloperKeys for Mobile Verify.
To Test:
- remove skip statements in examples
- uncomment the call to appium_init()
- verify appium_lib gem installs during bundle update
- spin up an Appium server
- run spec with the QA Nexus 7 connected
Change-Id: Ia9830aeaa0b91635f5739958466e3176f25bf2bb
Reviewed-on: https://gerrit.instructure.com/58562
Tested-by: Jenkins
Reviewed-by: Heath Hales <hhales@instructure.com>
Reviewed-by: Ben Bolton <bbolton@instructure.com>
QA-Review: Ben Bolton <bbolton@instructure.com>
Product-Review: Ben Bolton <bbolton@instructure.com>
What is this?
=============
Selinimum speeds up selenium by only running the specs it needs to for
your commit (iff it can safely determine that). For the purposes of the
initial implementation, that means that if your commit ONLY affects:
1. controllers (but not ApplicationController)
2. views (but not shared / layouts)
3. misc whitelisted stuff (images, .md files, etc.)
then it will only run the selenium specs that actually exercise those.
If your commit touches ANYTHING else (models, lib, etc.), all selenium
specs will run.
But wait, there's more!
=======================
Very soon selinimum will also handle:
1. js/coffee/jsx/hbs (except in the common bundle)
2. scss (except in the common bundle)
We already capture which bundles get used by each spec (see Capture), we
just need to correlate that with the individual files via a dependency
graph (probably using madge and sass-graph)
How does it work?
=================
The new post-merge selenium build will run all the specs with selinimum
capturing enabled. This records any controllers/views/js_bundle/css_bundle
that gets used in the course of each selenium spec, and stores a bunch of
data in S3.
Then when your patchset build runs, it will run Selinimum.minimize (via
corresponding tweak in rspect repo) on the list of spec files. If your
commit's dependents can be fully inferred and synthesized with the spec
dependency data from S3, only the relevant specs will actually be run.
Test Plan
=========
This commit doesn't actually cause selinimum to run on jenkins; that
requires some rspect changes and jenkins config. Refer to the test plan
here: https://gerrit.instructure.com/#/c/58088/
Change-Id: I991574c327a3a580c6fdc3ca3797dcfe0490a096
Reviewed-on: https://gerrit.instructure.com/58085
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Addresses vulnerability
a6c759d7e7
This gem is only used in dev/test, to generate the API docs. test plan: `rake
doc:api`, verify the docs still render correctly.
Change-Id: Ib1884ec5717bd6d252fa85cbfafb77f1be40ba24
Reviewed-on: https://gerrit.instructure.com/55350
Tested-by: Jenkins
Reviewed-by: August Thornton <august@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
add migration lint as rubocop cops
create frozen constant linter
find_ids datafixup lint
send_later lint
lint send_later in predeploys
add freeze_constant cop to default config
don't forget to include rubocop when running
get the rubocop runner into the script
lint for wrong algorithm name
lint primary key
lint remove_column in predeploys
get rubocop output as parsed json
diff munging for gergich
disable a few style cops
tweak rubocop setup to allow IDE plugins to work
get gergich comment format right
shell out to gergich if we're in jenkins-land
Change-Id: I6eecc8d8ede17a755c9d9a86121c3658776de9cd
Reviewed-on: https://gerrit.instructure.com/51755
Tested-by: Jenkins
Reviewed-by: Jason Madsen <jmadsen@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
we have them in the gemfile to lock them to a specific version,
but normal behavior doesn't auto-require them
also, use 1.9 hash syntax in gemfiles (_except_ _before.rb)
Change-Id: I549c2775c65d48ff23ba1358b43713965df97813
Reviewed-on: https://gerrit.instructure.com/51636
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
This commit adds a new module called LiveEvents that knows how to send a
certain set of events to Kinesis. The module is configured via
normal plugin settings per account. Once the plugin is configured with
a Kinesis stream, events will start getting sent to that stream.
Events are sent asynchronously, in a background thread.
test plan:
* See `doc/live_events.md` for instructions on how to setup a local
kinesis stream and configure the LiveEvents plugin.
* Start tailing the stream with the command specified in
`doc/live_events.md` in a terminal.
* Perform the actions described in `doc/api/live_events.md` and verify
that events show up in your Kinesis terminal with the correct data.
Change-Id: Id799688c972205a1eee84a673912f84b0c7abb57
Reviewed-on: https://gerrit.instructure.com/50324
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Product-Review: Zach Wily <zach@instructure.com>
see https://github.com/rails/rails/pull/18306 for discussion on
why it's not released yet
Change-Id: Id0de57432df9e7db1767c8f4d75c7734799148b9
Reviewed-on: https://gerrit.instructure.com/48828
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
rather than silently changing the values.
Fixes CNVS-17630
Test Plan:
Using the API:
- set an outcomes calculation_method to an illegal value
(anything besides 'decaying_average', 'n_mastery', 'latest',
and 'highest'
- Observe that you get an error message telling you it is an
illegal value.
- set an outcomes calculation_int to an illegal value
- Observe that you get an error message telling you it is an
illegal value.
- Repeat the check for calculation_int for each calculation_method
Change-Id: Ic310583f7c14b25a0425fa809c0307d1f3194961
Reviewed-on: https://gerrit.instructure.com/46300
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Adam Stone <astone@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
refs CNVS-15881
our delayed_job depends on this, so I'm pulling it out into a gem first,
so that we can fully gemify our fork of delayed_job and use it in other
apps.
I modified the code to be built on top of the after_commit callback
functionality added in rails3, and I pulled in the test_after_commit gem
(after making a fix to it), which emulates transaction callbacks in test
mode. This makes it easier to write tests that interacts with these
callbacks, and cleans up some code in the app that was checking for test
mode and changing behavior. Fortunately, it behaves well with once-ler.
Side note: now that we are on rails3, we could replace some, but not
all, of our usage of after_transaction_commit with after_commit AR
callbacks. I didn't do that in this commit, to minimize churn.
test plan: things that happen in commit callbacks should still happen as
expected. for instance, with caching enabled, changing a /plugins
setting should still take effect immediately, because the cache is
cleared in a commit callback.
Change-Id: I66af5f66bf9fa9354352ed37edec8bd92d8e39c8
Reviewed-on: https://gerrit.instructure.com/41819
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
while recording, we weren't wrapping the default shard in a transaction,
so side effects could carry over to other groups/examples.
additionally, the previous version of once-ler added recording hooks to
any sharding group, whether or not it actually had any recordings. this
was sub-optimal, and also problematic for non-transactional tests.
this fixes a slew of the rerun failures.
also get rid of the ConnectionEnumerator, since an array suffices and is
easier to reason about (it was just like an array, except #each yielded
connections)
Change-Id: I8cf4d6fb74f2b048017a33c4fc50313cc8e5c19c
Reviewed-on: https://gerrit.instructure.com/38713
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
fix a blocking thing, and add a compatibility gem
and a few final missed things
fixes CNVS-16239
Change-Id: I6ffa4569f936173393eaf7225f7463a4ccba1c7c
Reviewed-on: https://gerrit.instructure.com/42715
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <braden@instructure.com>
Product-Review: Braden Anderson <braden@instructure.com>
QA-Review: Braden Anderson <braden@instructure.com>
makes the lockfile the same between 1.9 and 2.1
Change-Id: I3ab1c3c7a7fcb8e6a5aba0170744d04739029209
Reviewed-on: https://gerrit.instructure.com/40753
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
closer to 3.0, which we probably don't want to go to until
we can drop rspec 1 (rails 2)
Change-Id: I8affc4882bfc927a6d3b9bcc9c43fe5ab92cd3b7
Reviewed-on: https://gerrit.instructure.com/37326
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
sometimes it's needed to debug stuff in 2.1, cause it
fixes SystemStackError
bundler doesn't support it yet, so we have to use conditionals
instead of platform options
Change-Id: I88614634d24f36d7c18c999c1dc65eb91df65a32
Reviewed-on: https://gerrit.instructure.com/37010
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
during a previous commit
(SHA 10e7b5b003bea9aea3286b9170f5e04b8a9e3735)
we removed indentation of gems, but this indentation
had semantic significance for us: any gem which was
not required by canvas but was required by another
gem required by canvas was indented. This allowed us
to clarify that canvas didn't actually use the gems
while still locking into specific versions of each
Also added a comment explaining this to Gemfile
Change-Id: I0f476e1bed6156f2f5969e54d56d44ded5442a0f
Reviewed-on: https://gerrit.instructure.com/32588
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
this is a proof-of-concept to see if partitioning
our Gemfile helps more than it hurts. It's modeled
after the way the Squash team handles its dependencies
this doesn't implement any of the particularly nice
things that can be found in the Squash set up, such
as conditionally loading gems based on the contents
of our configuration files (we can already sort of
do this with groups in bundler), but it's a start.
In particular, it allows us to add non-OSS gems to
Gemfile.d without necessarily having to release it
as part of our open-source packaging
Change-Id: If7ff1fe97409de4cd09867ad5be1c4134c5d0117
Reviewed-on: https://gerrit.instructure.com/32442
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
kinezu