Jenkins:尽管没有变化,SCM仍会触发持续构建

Question

我们遇到了一个问题,尽管没有代码更改,但SCM正在触发构建.SCM每15分钟轮询一次更改,并且只有在发现更改时才应触发构建.

以下是连续SCM轮询日志的几个示例.

Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found

Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found

Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found

正如您所看到的那样,修订版本与修订版本相同

Git Build Data

Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop

几天前,这些工作表现如预期.我们所知道的任何事情都没有改变我们的环境造成这种情况.

我升级到最新版本的Jenkins(1.539),并在昨晚安装了插件以解决此问题,但行为仍在继续.

Answer 1

由于SCM的变化,我刚刚遇到Jenkins,即使没有变化,也没有打开轮询.这可能与您的方案不同,但我认为它可能仍然有助于分享我的解决方案.

Out项目配置为使用分支说明符进行构建,*/integration就像我们所有其他集成构建一样.然而,在查看了我们的原始git repo上的所有分支之后,我看到有两个分支与说明*/integration符匹配.看起来开发人员必须错误地推送到一个名称非常相似的新分支:

$git branch --remote | grep integration
  origin/integration
  origin/origin/integration

解决这个问题的解决方案是使用完全指定分支refs/heads/integration.我假设它也可以简单地删除重复的违规分支,但通过准确指定分支,我可以避免将来遇到同样的问题.

我不确定这是否与您的问题相同,但这对我有用,并希望在这种情况下能为其他人工作.

Answer 2

似乎可以与最新的Jenkins GIT插件版本2.0 重现.

降级到版本1.x可能会解决问题.虽然你也应该从旧备份恢复Jenkins配置,因为GIT插件版本1.x似乎不能使用新的2.0配置方案.

该线程建议启用"快速远程轮询"作为解决方法.在2.0版本中,它被称为"使用工作空间强制轮询".

参考Jenkins问题:https://issues.jenkins-ci.org/browse/JENKINS-20767