合并之前生成Jenkins git插件选项不触发 [英] Merge Before Build Jenkins git plugin option not triggering

问题描述

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

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

在Jenkins的构建工作中，我们指定一个发布版本*作为要构建的分支，并且在构建之前指定git插件选项

我的期望在于，在开始构建每个发行版分支之前，插件会将它找到的所有发行版分支合并到主版本中。

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

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

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

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

然而，詹金斯似乎并没有尝试这种方式，尽管设置了合并之前合并选项。

 获取上游变更来自[e-mail]：xxxxxxx / test_repo.git 
> git --version＃timeout = 10 
> git fetch --tags --progress [e-mail]：xxxxxxx / test_repo.git 
 + refs / heads / *：refs / remotes / origin / * 
存储库origin / master中的分支
存储库origin / release1中的可见分支
存储库origin / release2中的可见分支
查看3个远程分支
检出修订版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 
设置构建名称。 
新建的名字是'＃8'
 [build-sharknado-app] $ / bin / sh -xe /tmp/hudson1678313403112351764.sh 
 + cat file.txt 
x = 7 
  

作业成功，我们看不到合并冲突。

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

解决方案

在这种情况下，Git插件按照设计进行工作。

所有分支正在进行版本更改扫描（基于Jenkins工作区中git回购的本地副本）。当找不到任何东西时，Jenkins仅对最近的提交进行操作。

Git插件不是用来将多个分支合并到同一个版本的master中。

在多个分支上检测到更改时，Jenkins会为每个分支启动一个新的构建作业。在每个作业中，相关分支都合并为主，但Jenkins使用-f选项检出主，这会在主服务器上重置HEAD，因此不会检测到多个分支合并到主服务器时产生的构建冲突。

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

Our development cycle maintains multiple concurrent release branches.

We want to have a reliable way to expose merge conflicts in release branches as early as possible in the cycle.

In our build jobs in Jenkins, we specify a glob of release* as the branch to build, and specify the git plugin option to "Merge Before Build" to master before the build is commenced.

My expectation here is that the plugin would merge all release branches it finds into master before commencing the build of each release branch.

I've set up a dummy repo to test this. The repo has one text file. There are 3 branches:

master (main) release1 (taken from master) release2 (taken from master)

I update the same line in the file in release1 and release2 to deliberately create a merge conflict which I have confirmed exists.

Now, when I build the job, I would expect Jenkins to try and merge release1 and release2 into master, where it would encounter the merge conflict and fail, which is what we want.

However, Jenkins doesn't seem to attempt this, despite the "Merge Before Build" option being set.

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

The jobs succeeds and we don't see the merge conflict.

Why is the merge of multiple release* branches to master not happening?

解决方案

In this case, the Git plugin is acting as designed.

All of the branches are being scanned for revision changes (based on local copy of the git repo in the Jenkins workspace). When none are found, Jenkins only acts on the most recent commit.

The Git plugin is not designed to merge multiple branches to master in the same build.

Where changes are detected on multiple branches, Jenkins launches a new build job for each branch. In each job, the relevant branch is merged to master, but Jenkins checks out master with the -f option, which resets the HEAD on master, so a build conflict that arises from multiple branches being merged to master is not detected.

This means that Jenkins can only detect a merge conflict that arises from merging one branch to another, and not a conflict that arises from merging 2 different branches to the same destination branch.

这篇关于合并之前生成Jenkins git插件选项不触发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！