Question

我们的开发周期维护着多个并发发布分支。

我们希望有一种可靠的方法在周期中尽早公开发布分支中的合并冲突。

在Jenkins的构建作业中，我们指定一个发布版本*作为要构建的分支，并指定git插件选项为＆＃34; Merge Before Build＆＃34;在构建开始之前掌握。

我的期望是，插件会在开始构建每个发布分支之前合并所有发布的分支，然后找到它们。

我已经设置了一个虚拟仓库来测试它。 repo有一个文本文件。有3个分支：

主人（主） release1（取自master） release2（取自大师）

我更新了release1和release2中文件中的同一行，故意创建了我已确认存在的合并冲突。

现在，当我构建作业时，我希望Jenkins尝试将release1和release2合并到master中，它会遇到合并冲突并失败，这就是我们想要的。

然而，Jenkins似乎没有尝试过这个，尽管＆＃34; Merge Before Build＆＃34;选项正在设定。

Fetching upstream changes from git@bitbucket.org:xxxxxxx/test_repo.git
 > git --version # timeout=10
 > git fetch --tags --progress git@bitbucket.org:xxxxxxx/test_repo.git 
 +refs/heads/*:refs/remotes/origin/*
 Seen branch in repository origin/master
 Seen branch in repository origin/release1
 Seen branch in repository origin/release2
 Seen 3 remote branches
 Checking out Revision 5b75c954f334a2fc6c683cd7304d4d84826f02cd 
(origin/release2, origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 5b75c954f334a2fc6c683cd7304d4d84826f02cd
 > git rev-list 5b75c954f334a2fc6c683cd7304d4d84826f02cd # timeout=10
 > git rev-list 5b75c954f334a2fc6c683cd7304d4d84826f02cd # timeout=10
 Set build name.
 New build name is '#8 '
[build-sharknado-app] $ /bin/sh -xe /tmp/hudson1678313403112351764.sh
+ cat file.txt
x=7

工作成功，我们没有看到合并冲突。

为什么多个release *分支的合并没有发生？

Answer 1

在这种情况下，Git插件按设计运行。

正在扫描所有分支以进行修订更改（基于Jenkins工作区中git仓库的本地副本）。如果没有找到，Jenkins只会对最近的提交行动。

Git插件并非旨在将多个分支合并到同一版本中的master。

在多个分支上检测到更改的情况下，Jenkins为每个分支启动新的构建作业。在每个作业中，相关分支合并为master，但Jenkins使用-f选项检出master，这会重置master上的HEAD，因此未检测到多个分支合并为master的构建冲突。

这意味着Jenkins只能检测到将一个分支合并到另一个分支时产生的合并冲突，而不是将两个不同分支合并到同一目标分支时产生的冲突。

构建之前合并Jenkins git插件选项不会触发

1 个答案: