1 files changed, 35 insertions, 0 deletions
diff --git a/db/migrate/20211012134316_clean_up_migrate_merge_request_diff_commit_users.rb b/db/migrate/20211012134316_clean_up_migrate_merge_request_diff_commit_users.rb
new file mode 100644
index 00000000000..443dbe37c0b
--- /dev/null
+++ b/db/migrate/20211012134316_clean_up_migrate_merge_request_diff_commit_users.rb
@@ -0,0 +1,35 @@
+# frozen_string_literal: true
+
+class CleanUpMigrateMergeRequestDiffCommitUsers < Gitlab::Database::Migration[1.0]
+  def up
+    jobs = Gitlab::Database::BackgroundMigrationJob
+      .for_migration_class('MigrateMergeRequestDiffCommitUsers')
+      .pending
+      .to_a
+
+    return if jobs.empty?
+
+    say("#{jobs.length} MigrateMergeRequestDiffCommitUsers are still pending")
+
+    # Normally we don't process background migrations in a regular migration, as
+    # this could take a while to complete and thus block a deployment.
+    #
+    # In this case the jobs have all been processed for GitLab.com at the time
+    # of writing. In addition, it's been a few releases since this migration was
+    # introduced. As a result, self-hosted instances should have their
+    # migrations finished a long time ago.
+    #
+    # For these reasons we clean up any pending jobs (just in case) before
+    # deploying the code. This also allows us to immediately start using the new
+    # setup only, instead of having to support both the old and new approach for
+    # at least one more release.
+    jobs.each do |job|
+      Gitlab::BackgroundMigration::MigrateMergeRequestDiffCommitUsers
+        .new
+        .perform(*job.arguments)
+    end
+  end
+
+  def down
+  end
+end