具体来说,如果用户 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,才发现这东西不是想的那么简单。