diff options
| author | Nick Thomas <nick@gitlab.com> | 2019-08-15 21:54:08 +0300 |
|---|---|---|
| committer | Mayra Cabrera <mcabrera@gitlab.com> | 2019-08-15 21:54:08 +0300 |
| commit | d31b733fee8fc739157ca0dc6f0d6fba7a8efc21 (patch) | |
| tree | 80ebfff6d4b94445954aa63e3c3eab476422454c /spec/services/merge_requests | |
| parent | cf5d64e25061411e0b28040afcaa08215efb949d (diff) | |
Only read rebase status from the model
Prior to 12.1, rebase status was looked up directly from Gitaly. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
column was added to track the status instead. However, we couldn't stop
looking at the gitaly status immediately, since some rebases may been
running across the upgrade.
Now that we're in 12.3, it is safe to remove the direct-to-gitaly
lookup. This also happens to fix a 500 error that is seen when viewing
an MR for a fork where the source project has been removed.
We still look at the Gitaly status in the service, just in case Gitaly
and Sidekiq get out of sync - I assume this is possible, and it's a
relatively cheap check.
Since we atomically check and set `merge_requests.rebase_jid`, we
should never enqueue two `RebaseWorker` jobs in parallel.
Diffstat (limited to 'spec/services/merge_requests')
| -rw-r--r-- | spec/services/merge_requests/rebase_service_spec.rb | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/spec/services/merge_requests/rebase_service_spec.rb b/spec/services/merge_requests/rebase_service_spec.rb index ee9caaf2f47..7b8c94c86fe 100644 --- a/spec/services/merge_requests/rebase_service_spec.rb +++ b/spec/services/merge_requests/rebase_service_spec.rb @@ -25,7 +25,7 @@ describe MergeRequests::RebaseService do describe '#execute' do context 'when another rebase is already in progress' do before do - allow(merge_request).to receive(:gitaly_rebase_in_progress?).and_return(true) + allow(repository).to receive(:rebase_in_progress?).with(merge_request.id).and_return(true) end it 'saves the error message' do |