詹金斯:尽管没有变化，SCM仍会触发稳定的构建 [英] Jenkins: SCM triggering constant builds despite no change

问题描述

我们有一个问题，尽管代码没有更改，但SCM仍在触发构建. SCM每15分钟轮询一次更改，并且仅在找到更改后才触发构建.

We have a problem where despite no code changes SCM is triggering a build. SCM polls for changes every 15 minutes and should only trigger a build if changes are found.

以下是连续SCM轮询日志的一些示例.

Here are a few examples of consecutive SCM polling log.

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

如您所见，修订版是相同的，并且与

As you can see the revision is the same and matches that of

Git Build Data

Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop

直到几天前，这些作业的表现均符合预期.我们知道没有什么事情会导致环境发生变化.

These jobs behaved as expected until a few days ago. There is nothing that we're aware that has changed about our environment to cause this.

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

I upgraded to the latest version of Jenkins (1.539) and installed plug-ins last night in a effort to resolve this but the behavior continues.

推荐答案

由于SCM的变化，即使没有变化，我也一直遇到Jenkins不断构建的问题，甚至没有打开轮询.这可能与您的情况有所不同，但我认为它仍然可能有助于分享我的解决方案.

I just ran into Jenkins continuously building due to an SCM change, even when there was no change, and polling was not even turned on. This may be different from your scenario but I figured it may still help to share my solution.

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

Out project is configured to build using the branch specifier */integration just like all of our other integration builds. However, after looking at all of the branches on our origin git repo, I saw that there are two branches that matched the */integration specifier. It looks like a developer must have erroneously pushed to a new branch with a very similar name:

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

为我解决此问题的解决方案是使用refs/heads/integration完全指定分支.我认为删除简单的重复分支也可以，但是通过精确地指定分支，可以避免以后再遇到相同的问题.

The solution that fixed this issue for me was to specify the branch fully, using refs/heads/integration. I assume it would also work to simply delete the duplicate offending branch, but by specifying the branch exactly I can avoid running into the same problem in the future.

我不确定这是否是您遇到问题的原因，但这对我有用，并且希望在这种情况下可以对其他人有用.

I'm not sure this is the same cause for your problem but this is what worked for me, and hopefully will work for someone else in this situation.

这篇关于詹金斯:尽管没有变化，SCM仍会触发稳定的构建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！