diff options
author | Nick Thomas <nick@gitlab.com> | 2019-06-21 19:56:47 +0300 |
---|---|---|
committer | Nick Thomas <nick@gitlab.com> | 2019-07-04 10:50:55 +0300 |
commit | 381468d0cc6e5b528a4b2207c0a534569035a73f (patch) | |
tree | 2ffc9e9062fef50a7cca8dfd8d0b5733e8cf4c9d /spec/requests | |
parent | 9ef0c8559de925d0a72a3fe421d95209c2b81d8f (diff) |
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.
Diffstat (limited to 'spec/requests')
-rw-r--r-- | spec/requests/api/merge_requests_spec.rb | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/spec/requests/api/merge_requests_spec.rb b/spec/requests/api/merge_requests_spec.rb index a82ecb4fd63..ced853caab4 100644 --- a/spec/requests/api/merge_requests_spec.rb +++ b/spec/requests/api/merge_requests_spec.rb @@ -2033,6 +2033,9 @@ describe API::MergeRequests do expect(response).to have_gitlab_http_status(202) expect(RebaseWorker.jobs.size).to eq(1) + + expect(merge_request.reload).to be_rebase_in_progress + expect(json_response['rebase_in_progress']).to be(true) end it 'returns 403 if the user cannot push to the branch' do @@ -2043,6 +2046,16 @@ describe API::MergeRequests do expect(response).to have_gitlab_http_status(403) end + + it 'returns 409 if a rebase is already in progress' do + Sidekiq::Testing.fake! do + merge_request.rebase_async(user.id) + + put api("/projects/#{project.id}/merge_requests/#{merge_request.iid}/rebase", user) + end + + expect(response).to have_gitlab_http_status(409) + end end describe 'Time tracking' do |