gitlab-org--gitlab-foss/db/migrate/20160419122101_add_only_all...

# rubocop:disable Migration/UpdateLargeTable
class AddOnlyAllowMergeIfBuildSucceedsToProjects < ActiveRecord::Migration[4.2]
  include Gitlab::Database::MigrationHelpers
  disable_ddl_transaction!

  def up
    add_column_with_default(:projects,
                            :only_allow_merge_if_build_succeeds,
                            :boolean,
                            default: false)
  end

  def down
    remove_column(:projects, :only_allow_merge_if_build_succeeds)
  end
end
Prevent update_column_in_batches on large tables add_column_with_default is implemented in terms of update_column_in_batches, but update_column_in_batches can be used independently. Neither of these should be used on the specified large tables, because they will cause issues on large instances like GitLab.com. This also ignores the cop for all existing migrations, renaming AddColumnWithDefaultToLargeTable where appropriate. 2017-11-17 13:38:14 +00:00			`# rubocop:disable Migration/UpdateLargeTable`
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-13 07:27:31 +00:00			`class AddOnlyAllowMergeIfBuildSucceedsToProjects < ActiveRecord::Migration[4.2]`
Allow or not merge MR with failed build Signed-off-by: Rémy Coutable <remy@rymai.me> 2016-04-27 18:34:42 +00:00			`include Gitlab::Database::MigrationHelpers`
			`disable_ddl_transaction!`

			`def up`
			`add_column_with_default(:projects,`
			`:only_allow_merge_if_build_succeeds,`
			`:boolean,`
			`default: false)`
			`end`

			`def down`
			`remove_column(:projects, :only_allow_merge_if_build_succeeds)`
			`end`
			`end`