gitlab fast-forward 疑问

Summary

承接之前提的一个这个issue：gitlab fast-forward快进式合并需要rebase

客户gitlab 界面配置

• 合并方法 模式： fast-forward

  展开

  

• 合并检查：

  • pipeline must succeed
  • all threads must be resolved
  展开

  

因为客户认为上面两个截图的配置引发MR合入不了，是一个严重的bug问题，MR触发的流水线在运行过程中，只要主干分有其他提交合入，就会让开发分支永无止境的rebase，再运行开发分支流水线，运行完成再让rebase，再触发流水线……导致MR始终无法合入。

Steps to reproduce

Example Project

What is the current bug behavior?

MR触发的流水线在运行过程中，只要main分支有新提交，就会让开发分支执行rebase，rebase后自动触发开发分支流水线，流水线运行完成后，检测main分支又有新提交，又让rebase后再次触发流水线……实际的业务场景中，pipeline构建时长半小时到1小时等都很常见，无法避免这期间主干分支有新提交，导致开发发起MR要一直执行rebase触发pipeline，始终无法合入

What is the expected correct behavior?

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)

Possible fixes（针对这个bug的改进需求，客户提供了如下参考）

Merge request新增一个选项，支持以下功能:

• 与fast forward merge的功能相同的两点:
  • 1.MR合入不产生“merge xxx branch to main”的空提交
  • 2.MR触发的流水线成功，合入前检测main分支是否有新提交，让用户rebase，如无冲突则rebase成功，如有冲突提示要解冲突
• 不同点:
  • 1.rebase成功后不再触发开发分支新的流水线，根据开发分支MR触发的流水线已成功，允许用户合入。