Automatically update MR merge-ref along merge status

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

1 files changed, 25 insertions, 0 deletions

diff --git a/db/post_migrate/20190620112608_enqueue_reset_merge_status_second_run.rb b/db/post_migrate/20190620112608_enqueue_reset_merge_status_second_run.rb
new file mode 100644
index 00000000000..2d096a2a39c
--- /dev/null
+++ b/db/post_migrate/20190620112608_enqueue_reset_merge_status_second_run.rb
@@ -0,0 +1,25 @@
+# frozen_string_literal: true
+
+# See http://doc.gitlab.com/ce/development/migration_style_guide.html
+# for more information on how to write migrations for GitLab.
+
+class EnqueueResetMergeStatusSecondRun < ActiveRecord::Migration[5.1]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+  BATCH_SIZE = 10_000
+  MIGRATION = 'ResetMergeStatus'
+  DELAY_INTERVAL = 5.minutes.to_i
+
+  disable_ddl_transaction!
+
+  def up
+    say 'Scheduling `ResetMergeStatus` jobs'
+
+    # We currently have more than ~5_000_000 merge request records on GitLab.com.
+    # This means it'll schedule ~500 jobs (10k MRs each) with a 5 minutes gap,
+    # so this should take ~41 hours for all background migrations to complete.
+    # ((5_000_000 / 10_000) * 5) / 60 => 41.6666..
+    queue_background_migration_jobs_by_range_at_intervals(MergeRequest, MIGRATION, DELAY_INTERVAL, batch_size: BATCH_SIZE)
+  end
+end