Commit Graph

6 Commits

Author SHA1 Message Date
Jan Provaznik 0fc9f9d3e7 Add version 4.2 to all existing migrations
DB schema generated by a migration may look different in
rails 4 and 5 (because rails 5 may use different default values).
For this reason it's important to explicitly set for which rails
version a migration was written for.

See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912
2018-11-22 13:18:28 +01:00
Lin Jen-Shin b95da565cd Enable rubocop for db/**/* and ee/db/**/* 2018-07-25 17:47:12 +08:00
Sean McGivern 1ab33b15d1 Add cop for use of remove_column
remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.
2017-12-11 16:34:51 +00:00
blackst0ne bc00806a4e Add database helpers 'add_timestamps_with_timezone' and 'timestamps_with_timezone' 2017-06-13 22:44:13 +11:00
Lin Jen-Shin 99294e09b8 Do nothing if ci_builds.job_id isn't there
This is really weird. I think we did get the same issue while
migrating on GitLab.com. We fixed this by adding job_id to
ci_builds table manually, and then run the migrations again.
However I think we didn't hit into this on staging, which should
somehow be a production clone.

At any rate, I guess we could check if the column exists in the
migration. If the column is not there, there's no point to remove
that column anyway.

Closes #29976
2017-03-24 22:13:01 +08:00
Kamil Trzciński 12dd5ac221 All CI offline migrations 2017-03-17 23:06:11 +00:00