转载

版本控制 – 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

原文  https://codeday.me/bug/20181015/293906.html
正文到此结束
Loading...