你的意思是搞个 webhook feature 分支，每次这个分支有代码更新就触发构建发布，发布后做校验？然后你的检验是想怎么做？代码扫描还是跑自动化测试？

feature 分支 merge request 到 master 分支前肯定有很多基于 feature 分支的提交，那这部分提交有没有 CI? 如果有能做到说代码 merge 前做 CI 检验吗？

如果一个 feature 分支做 merge request 到 master 分支操作时，通过 webhook, feature 分支可以在做 merge request 的时候有 CI。那研发日常 push 代码到这个 feature 分支会有 CI 吗？
--有，只要存在 feature 分支作为源分支的 mr，feature 每一次更新都会发送一个 mr 请求，都会触发 CI
能做到代码 merge 到 feature 分支前做 CI 检验吗？
--可以，我们用的 jenkins+gitlab 的方案，checkout 有一个 PreBuildMerge 参数，可以实现本地合并后再用合并代码做 CI，若有冲突直接失败，合并不会 push 到服务端，只做 CI。

谢谢你的回答，我知道所有 MR 操作都可以做前置 CI。但我的问题是日常 push 到 feature 分支的代码怎么做前置 CI？我的理解 feature 分支研发 push 代码就直接进那个 feature 分支代码库了。

你没有代码仓库权限吗？进去看一眼立刻就明白了……
可以配置多个 hook，MR 的配置 MR 的 CI 启动接口，Push 的（可以指定分支）URL 配置 Push 对应的 CI 启动接口

Gitlab 的那几种 webhook 我知道，我的意思是有没有办法拦截 push 的提交，然后跑前置 CI，CI 过了在进代码库，想达到的效果有点类似 gerrit 的 patchset created 的效果。监听 push events 只能是说代码进去了再跑个 CI。

预拦截 commint、push 只能通过项目下发本地的 hook 来实现，比较复杂，而且比较容易在本地被篡改。

好的，所以 Gitlab 直接 push 到分支的代码只能说代码进去后触发 CI。如果 CI 有问题要么提交修复代码，要么 revert 之前代码，没办法说代码真正进代码库前触发 CI 拦截然后拒绝掉。

CI 实施的前提就是版本控制吧，你可以把 local build 当做 CI 检查？或者在 feature 分支上拉个人分支开发，然后走 MR？

换个思路，自己拿树莓派控制几个无人机、气球炸弹啥的，对于本地没有事先 CI 搞通直接 push 上去的，CI 一旦跑红了，开飞机去炸丫的，然后通过度量数据公示出来……

@AngryTester @ 槽神 不同的 workflow 确实有不一样的策略，谢谢二位上面的回复。

请问楼主 push 前的 ci 有没有解决方案了啊？