詹金斯GitHub插件逆向分支

Question

我在插件页面有一个问题，但这似乎是詹金斯支持更积极的地方。

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

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

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

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

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 

有趣的配置选项

分行建立

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

排除的用户

jenkins 
ConvergintJenkins 

合并选项

✓ Merge before build 
Branch to merge to 
    develop 

禁用子模块处理 ✓

选择战略前导

Inverse 

构建触发

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

Git的投票登录

Polling has not run yet. 

Github上挂钩登录

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 

Answer 1

看起来你在这里有两个问题。

1. 您不想构建的分支正在构建中。
2. 您正在看到一些时髦的合并行为（可能是由于上述原因）。

我认为你的诊断是正确的 - I am beginning to assume that the Github plugin does not respect the choosing strategy or the other git plugin options。

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

在我看来，如果你把所有东西都回归到基础知识，你就不会出错。像使用任何Git仓库一样，使用Jenkins Git插件并对待GitHub。设置SSH或类似（useful help article here）和一个体面的投票间隔，你不应该遇到任何问题！

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