版本控制 – Jenkins：尽管没有变化,SCM也会触发常量
我们有一个问题,尽管没有代码更改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
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
