Jenkins GitHub插件反向分支 [英] Jenkins GitHub Plugin Inverse Branches

问题描述

我在插件页面有一个问题，但这似乎是Jenkins支持的一个更加活跃的地方。

当更改被推送到任何分支该工作将运行，并合并到开发部门，但大约20秒后，该工作将注意到合并到开发中并再次触发该工作。这不应该发生，因为发展是在分支建设（反选择stragety）。这种情况也会发生，当它推动到主或释放时，这也应该被排除。如果出现合并失败，那么作业将启动一个永无止境的循环，试图合并分支，直到手动解决冲突为止。

我也尝试排除特定用户从触发构建，也没有效果。

我开始认为Github插件不尊重选择策略或其他git插件选项。

希望以下信息能够帮助我解决这个问题。

  GitHub Plugin => 1.5 
 GitHub API插件=> 1.40 
 GitHub Pull Request Builder => 1.7 
 GitHub身份验证插件=> 0.13.1 
 Jenkins GIT Plugin => 1.3.0 
 Jenkins GIT客户端插件=> 1.0.5 
  

构建中有趣的配置选项

<分行建立

  master，** master，release，** release，develop，** develop 
  

排除用户

  jenkins 
 ConvergintJenkins 
  

合并选项

 ✓合并之前合并
分支合并为
 develop 
  

禁用子模块处理
✓

选择stragety

 逆向
  

建立触发器

 ✓当更改推送到github 
时进行构建b轮询SCM 
  

Git轮询日志

 轮询尚未运行。 
  

Github Hook Log

 开始于2013年4月30日下午3点53分14秒
使用策略：反转
 [poll]上次修正版本：修订版本bde1981da849dbfb2fd93aac4de05fd5a832043b（原始/ ach）
获取更改从远程Git存储库获取
从原始数据获取上游变更
在
中查询变更的轮询在源数据库中查看分支/ develop 
在数据库origin / feature-228中查看分支
资源库中的已知分支origin / feature-249 
资源库原始/主资源中的可见分支
资源库原始/版本中的可见分支
完成。花了1.4秒
更改发现
  

解决方案

就像你在这里遇到了两个问题一样。

1. 您不想构建的分支正在构建中。


2. 您看到了一些时髦的合并行为（可能是出于上述原因）。

我认为您的诊断是正确的 - 我开始认为Github插件不尊重选择策略或其他git插件选项。

过去我也有过各种GitHub插件的问题。他们有一些很好的配置选项，可以做一些聪明的事情，但最终可能会有点片面。我坚信，在CI管道中绝对不应该有轻微的地方（因为它会导致对它缺乏信任）。

在我看来，你不能如果你把所有东西都还原成基础，就会出错。使用Jenkins Git插件并像对待任何Git存储库一样对待GitHub。设置SSH或类似（这里有用的帮助文章）和一个体面的投票间隔，你不应该运行到任何问题！

我已经为我的组织使用私人GitHub存储库以这种方式设置了数百个Jenkins作业。希望这有助于。

I have a question in on the plugins page, but this seems to be a much more active place for Jenkins support.

When a change is pushed to any branch the job will run, and merge into the develop branch, but approx 20 seconds later the job will notice the merge into develop and trigger the job again. This should not happen because develop is in the branches to build (with inverse choosing stragety). This also happens when a change it pushed to master or release, which also should be excluded. If there is a merge failure then the job will start a never ending loop trying to merge the branches until the conflict is manually resolved.

I have also tried to exclude a specific user from triggering builds, also to no effect.

I am beginning to assume that the Github plugin does not respect the choosing strategy or the other git plugin options.

Hopefully the below information is all that is needed to help me wrap my head around this issue.

GitHub Plugin                => 1.5
GitHub API Plugin            => 1.40
GitHub Pull Request Builder  => 1.7
GitHub Authentication Plugin => 0.13.1
Jenkins GIT Plugin           => 1.3.0
Jenkins GIT client Plugin    => 1.0.5

Interesting Configuration options from build

Branches to build

master,**master,release,**release,develop,**develop

Excluded Users

jenkins
ConvergintJenkins

Merge options

✓ Merge before build
Branch to merge to
    develop

Disable submodule processing ✓

Choosing stragety

Inverse

Build Triggers

✓ Build when a change is pushed to github
✓ Poll SCM

Git Polling Log

Polling has not run yet.

Github Hook Log

Started on Apr 30, 2013 3:53:14 PM
Using strategy: Inverse
[poll] Last Built Revision: Revision bde1981da849dbfb2fd93aac4de05fd5a832043b (origin/ach)
Fetching changes from the remote Git repositories
Fetching upstream changes from origin
Polling for changes in
Seen branch in repository origin/develop
Seen branch in repository origin/feature-228
Seen branch in repository origin/feature-249
Seen branch in repository origin/master
Seen branch in repository origin/release
Done. Took 1.4 sec
Changes found

解决方案

It looks like you've got two problems here.

1. The branches you don't want to build are being built.
2. You're seeing some funky merging behaviour (probably as a result of the above point).

I think your diagnosis is correct - I am beginning to assume that the Github plugin does not respect the choosing strategy or the other git plugin options.

I've had problems with the various GitHub plugins in the past too. They have some nice configuration options and can do some clever things but ultimately can be a bit flaky. I strongly believe that there should be absolutely no place for flakiness in a CI pipeline (as it will lead to a lack of trust in it).

In my opinion you cannot go wrong if you strip everything back to basics. Use the Jenkins Git plugin and treat GitHub as you would any Git repository. Set up SSH or similar (useful help article here) and a decent polling interval and you shouldn't run into any problems!

I have set up hundreds of Jenkins jobs in this manner for my organisation which uses private GitHub repositories. Hope this helps.

这篇关于Jenkins GitHub插件反向分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！