请教， gitlab CI 预检构建的实践

[twistedmeadows]

具体来说，如果用户 push 或 merge request，触发 pipeline 去执行构建和测试，当然是合理的。
但是，如果测试的只是他提交的这个 branch，那显然是不充分的，因为存在一种边界情况是:测试在 source branch 上能通过，在 master 上也能通过，但 merge 执行后反而不能通过。

也就是说，当有两个人分别修改了代码的不同部分，但这两部分又有隐含的逻辑相关性，那么就存在一种可能是，两个人的代码都能跑过，但合到一起会跑不过。


所以期望 gitlab CI 在被 merge request 触发后，不是做当前 source branch 的构建和测试，而是把这个 branch 与 master 做一次预合并，再基于合并后的代码做构建和测试。

想问下这种需求的最佳实践是怎样操作？直接在 build stage 里写 git 操作的 script 来执行 merge 吗？还是有别的聪明的办法？
按我理解这个需求是很常见的，Gitlab CI 也许内建了这个功能。但是没搜到。


以前在大厂都是前辈们全部配好的直接用，现在在小公司，需要自己管 CI，才发现这东西不是想的那么简单。

[BrettD]

Travis CI 和 GitHub Action 都是自动把 PR 分支 rebase 到 master 之后再开始跑编译和测试，GitLab 不会没有这功能吧

[mazyi]

https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html

[learningman]

你这个想法不合理，假设有 n 个分支，那一次 push 就有 2^n 种组合
应该在 PR 的时候检查

[twistedmeadows]

@mazyi 感谢！之前没注意到是这个关键词

[sfqtsh]

可强制 fast forward merge

[nuistzhou]

@learningman 楼主说的是 push 当前这个分支，那只需要 rebase 到 master 上然后走 ci 流程就行了啊，关别的分支什么事。

[julyclyde]

merge 也是一种 commit 啊。在 commit 的时候测试

[twistedmeadows]

@julyclyde 但是这个时候 merge 已经发生了，如果 fail，还得人工执行手动回退。
我不是说这种代价不可承受，只是觉得 CI 就是用来拦截这种不期望引入的 bug 的。能直接提前发现当然更好。
因为 CI 跑不过的代码连 reviewer 也不必花功夫去审了。

[julyclyde]

@twistedmeadows 那你这个需求，可能需要在某个 pre hook 里执行检查吧