2017-09-27 163 views
0

我们的开发周期维护多个并发发布分支。合并之前生成Jenkins git插件选项不触发

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

在Jenkins的构建工作中,我们指定了一个发布*作为要构建的分支,并在构建开始之前指定git插件选项“合并之前构建”。

我的期望是这个插件会合并全部发现分支,然后开始构建每个发布分支。

我设置了一个虚拟回购来测试这个。回购有一个文本文件。有3个分支:

主(主) release1(从主拍摄) release2(从主拍摄)

我更新release1和release2文件中的同一行刻意制造的合并冲突,我已经证实存在。

现在,当我创建这个工作时,我期望Jenkins尝试将release1和release2合并到master中,在那里它会遇到merge冲突并失败,这就是我们想要的。

但是,詹金斯似乎并没有尝试这一点,尽管设置了“合并之前合并”选项。

Fetching upstream changes from [email protected]:xxxxxxx/test_repo.git 
> git --version # timeout=10 
> git fetch --tags --progress [email protected]: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 

工作成功,我们看不到合并冲突。

为什么多个版本*分支合并到master不会发生?

+0

'git checkout -f 5b75c954f334a2fc6c683cd7304d4d84826f02cd'。特定的提交已签出,因此它处于分离的HEAD状态。尽管'origin/master'指向'5b75c954f334a2fc6c683cd7304d4d84826f02cd',分支'master'没有被检出,因此不在本地存在。这可能是原因。 – ElpieKay

+0

这似乎是问题,但我不知道为什么提交正在检出。我将“origin/release *”指定为“要建立的分支”选项,并且存在这些分支。但是,只有版本2被合并为主版本的一部分。 –

回答

0

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

正在扫描所有分支的版本更改(基于Jenkins工作区中git回购的本地副本)。如果没有发现,Jenkins仅对最近的提交进行操作。

Git插件没有设计用于在同一个版本中合并多个分支到主控。

在多个分支上检测到变化的地方,Jenkins为每个分支启动一个新的构建作业。在每项工作中,相关分支都合并为主,但Jenkins使用-f选项检出主设备,这会重置主设备上的主设备,因此不会检测到由多个分支合并为主设备而引发的构建冲突。

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