gitlab-org--gitlab-foss/db/migrate/20190621151636_add_merge_request_rebase_jid.rb

# frozen_string_literal: true

class AddMergeRequestRebaseJid < ActiveRecord::Migration[5.1]
  DOWNTIME = false

  def change
    add_column :merge_requests, :rebase_jid, :string # rubocop:disable Migration/AddLimitToStringColumns
  end
end
Allow asynchronous rebase operations to be monitored This MR introduces tracking of the `rebase_jid` for merge requests. As with `merge_ongoing?`, `rebase_in_progress?` will now return true if a rebase is proceeding in sidekiq. After one release, we should remove the Gitaly-based lookup of rebases. It is much better to track this kind of thing via the database. 2019-06-21 12:56:47 -04:00			`# frozen_string_literal: true`

			`class AddMergeRequestRebaseJid < ActiveRecord::Migration[5.1]`
			`DOWNTIME = false`

			`def change`
Adds cop to enforce string limits on migrations This cop will analyze migrations that add columns with string, and report an offense if the string has no limit enforced Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/64505 2019-08-23 17:36:12 -04:00			`add_column :merge_requests, :rebase_jid, :string # rubocop:disable Migration/AddLimitToStringColumns`
Allow asynchronous rebase operations to be monitored This MR introduces tracking of the `rebase_jid` for merge requests. As with `merge_ongoing?`, `rebase_in_progress?` will now return true if a rebase is proceeding in sidekiq. After one release, we should remove the Gitaly-based lookup of rebases. It is much better to track this kind of thing via the database. 2019-06-21 12:56:47 -04:00			`end`
			`end`