请教， gitlab CI 预检构建的实践
twistedmeadows · 2021-02-27 09:51:54 +08:00 via iPhone · 2771 次点击这是一个创建于 1365 天前的主题，其中的信息可能已经有所发展或是发生改变。
具体来说，如果用户 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，才发现这东西不是想的那么简单。
但是，如果测试的只是他提交的这个 branch，那显然是不充分的，因为存在一种边界情况是:测试在 source branch 上能通过，在 master 上也能通过，但 merge 执行后反而不能通过。
也就是说，当有两个人分别修改了代码的不同部分，但这两部分又有隐含的逻辑相关性，那么就存在一种可能是，两个人的代码都能跑过，但合到一起会跑不过。
所以期望 gitlab CI 在被 merge request 触发后，不是做当前 source branch 的构建和测试，而是把这个 branch 与 master 做一次预合并，再基于合并后的代码做构建和测试。
想问下这种需求的最佳实践是怎样操作？直接在 build stage 里写 git 操作的 script 来执行 merge 吗？还是有别的聪明的办法？
按我理解这个需求是很常见的，Gitlab CI 也许内建了这个功能。但是没搜到。
以前在大厂都是前辈们全部配好的直接用，现在在小公司，需要自己管 CI，才发现这东西不是想的那么简单。
 |
1
BrettD 2021-02-27 10:22:55 +08:00 via iPhone  1
Travis CI 和 GitHub Action 都是自动把 PR 分支 rebase 到 master 之后再开始跑编译和测试，GitLab 不会没有这功能吧
|
 |
2
mazyi 2021-02-27 11:04:14 +08:00 2
|
 |
3
learningman 2021-02-27 11:39:06 +08:00 via Android
你这个想法不合理，假设有 n 个分支，那一次 push 就有 2^n 种组合
应该在 PR 的时候检查 |
 |
4
twistedmeadows OP @mazyi 感谢！之前没注意到是这个关键词
|
 |
5
sfqtsh 2021-02-27 12:27:56 +08:00 via Android
可强制 fast forward merge
|
 |
6
nuistzhou 2021-02-27 15:25:22 +08:00 via iPhone
@learningman 楼主说的是 push 当前这个分支，那只需要 rebase 到 master 上然后走 ci 流程就行了啊，关别的分支什么事。
|
 |
7
julyclyde 2021-02-28 09:48:51 +08:00
merge 也是一种 commit 啊。在 commit 的时候测试
|
|
8
twistedmeadows OP @julyclyde 但是这个时候 merge 已经发生了，如果 fail，还得人工执行手动回退。
我不是说这种代价不可承受，只是觉得 CI 就是用来拦截这种不期望引入的 bug 的。能直接提前发现当然更好。 因为 CI 跑不过的代码连 reviewer 也不必花功夫去审了。 |
|
9
julyclyde 2021-03-01 12:06:39 +08:00
@twistedmeadows 那你这个需求，可能需要在某个 pre hook 里执行检查吧
|
Select Language