Git/Gerrit Jenkins持续集成：如何处理变基需求

Question

我有一个关于使用Jenkins进行Git/Gerrit持续集成的问题：当Git更改需要变基/合并时，是否有任何取消Jenkins作业执行的方法，因为在等待期间先前的更改已被接受？

最好的问候，

- Skywolf

---

如果 Gerrit 无法自动合并，则应对更改进行审核和验证。因此，我不会跳过它。我认为这是不能被跳过的，因为作业会在“Patchset created”触发，并且在这种情况下，合并/变基是一个新的补丁集。 - laplasz

如何在不提交补丁集的情况下确定是否需要进行rebase/merge？但是提交之前需要进行验证。而验证是由你的Jenkins作业完成的，对吗？ - laplasz

据我理解，如果当前修订 ID 与 Git HEAD 修订 ID 不同，则需要对补丁集进行变基/合并，是吗？既然无论如何都需要重新构建，那么应该跳过当前构建，并在 Gerrit 中仅投票“失败”以进行验证即可。 - Skywolf

如果这个补丁集是可以快进的，或者Gerrit自己可以合并/变基，那么在您提交后，您的更改就不会得到新的补丁集，它只是简单地合并了。因此，仅当合并在您修改的同一文件上进行时才会创建新的补丁集。 - laplasz

如果 Gerrit 检测到需要 rebase/merge，那么它应该跳过验证 - 但我认为这是无法检测的 - 因为只有在另一个变更在您创建补丁集并尝试提交之间提交时才会手动合并 - 但这意味着验证已经开始在您的补丁集上进行。 - laplasz

Answer 1

经过调查，我发现了一种检测潜在合并冲突的方法。一个基于Windows的Shell脚本如下所示：

git fetch
git merge-base HEAD origin/master > _base
set /p MERGEBASE=<_base
git merge-tree %MERGEBASE% HEAD origin/master | grep -E -A3 "changed in both">_tempDiff
cat _tempDiff
set /p VAR=<_tempDiff
if not "%VAR%"=="" (
      echo "Your change needs rebase"
      exit /b -1
)
exit /b 0

如果在 Gerrit 验证构建的最开始运行此脚本，当当前分支与最新的主分支修改同一文件时，构建将立即中断，通常用户必须在构建后在 Gerrit 中进行变基。

- Skywolf