[Bug] GitLab MR status is not proper when MR commits rebased to target branch and source branch deletion happens in a less time interval
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
GitLab MR status can either be one of the state - opened, closed, locked, or merged. We experienced a MR with status being closed and followed by merged in few secs. In other case where in the timeline of the MR it is captured as merged and followed by closed.
Steps to reproduce
Currently we are using a open source bot - https://gitlab.com/marge-org/marge-bot which helps to batch/combine MRs and rebase them to target branch once batch CI passes. This helps to reduce the amount of time a dev has to rebase his/her MR and wait for CI to pass to be able to merge it.
We experienced a problem/bug in the following scenario: 2) Marge-bot will create a branch (Batch branch) containing commits from both MRs. 3) Marge-bot pushes the branch to remote GitLab and wait for the CI to pass 4) Once CI passed, marge-bot will rebase individual branches(open MRs) with master and push it directly to master.
- Assign 2 MRs to marge-bot once CI passed for individual MRs After commits from MR are landed in master, below 2 operations are performed:
4.1) GitLab will mention in the MR "Mergeme merged manually" and change the state of the MR to merged 4.2) Marge-bot will delete the source branch once commits are landed in master
Now the problem is 4.1) and 4.2) are getting collided, since marge-bot deletes the branch - MR gets updated with the status as closed and GitLab detects the commits which are landed in master and changes the status of the MR to "Merged". Also we noticed that this happens only when there is large number of commits to rebase in source branch(MR). Hence we suspect GitLab Sidekiq: Looks to be there are two workers working independently and doesn't know each other's status like below
- Gets the updated status from master, once commits are landed to master from the MR
- Closes the MR because "Marge-bot" deletes the branch once commits are rebased and pushed to target/master branch.
Example Project
This happened in our prod environment. I didn't tested this in gitLab.com since this needs merge-bot to be operated against a project in GitLab and it also has api limitations.
What is the current bug behavior?
MR status timeline should reflect a single state
What is the expected correct behavior?
MR status timeline reflects closed followed by merged or merged followed by closed
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)(we will only investigate if the tests are passing)