also pins all migrations to Rails 4.2 semantics
Change-Id: I386566f7a1f3e3e8aa31675f467c87c443457aee
Reviewed-on: https://gerrit.instructure.com/95571
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Simon Williams <simon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-5180
the original migration had a regression since it was originally run;
fix the regression, and any dbs that have been migrated since that
regressions was introduced
Change-Id: I773c53a371364b238c9330481f1c1a7fdf472aa1
Reviewed-on: https://gerrit.instructure.com/26010
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-3902
even if the preference is that they don't
test plan:
* bring up a fresh database
* it should not fail
Change-Id: I5e7b2cf8479de4b3f1564ee65cd1cb456ae4674e
Reviewed-on: https://gerrit.instructure.com/17873
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Further experience has shown this to be a better fit for the job and
admin page queries.
This migration has only run on dev boxes so far, so this is a
replacement migration rather than a second migration.
Change-Id: Ibdde713efa3940d6e05af71a4ee792ef505c4ae9
Reviewed-on: https://gerrit.instructure.com/11727
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>