我们有一个问题,尽管没有代码更改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),并在昨天安装了插件,以解决这个问题,但行为仍在继续.
即使没有改变,我也因为SCM的改变而不断的建立jenkins,甚至没有打开投票.这可能与您的场景不同,但我认为它可能仍然有助于分享我的解决方案.
Out项目配置为使用分支说明符* /集成来构建,就像我们所有的其他集成构建一样.然而,在看到我们的原始git repo上的所有分支后,我看到有两个分支与* /整合说明符匹配.看起来开发人员必须错误地推送到一个名称相似的新分支:
$git branch --remote | grep integration origin/integration origin/origin/integration
解决这个问题的解决方案是使用refs / heads / integration完全指定分支.我认为也可以简单地删除重复的违规分支,但是通过指定分支,我可以避免在将来遇到同样的问题.
我不知道这是你的问题的同一个原因,但这对我有用,希望在这种情况下为别人工作.
http://stackoverflow.com/questions/20007854/jenkins-scm-triggering-constant-builds-despite-no-change