我们遇到了一个问题,尽管没有任何代码更改,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)并安装了插件,试图解决这个问题,但问题仍然存在。
7条答案
按热度按时间lymgl2op1#
我刚刚遇到Jenkins由于SCM变更而持续构建,甚至在没有变更的情况下也是如此,轮询甚至没有打开。这可能与您的方案不同,但我认为分享我的解决方案可能仍然会有所帮助。
我们的项目被配置为使用分支说明符
*/integration
进行构建,就像我们所有其他的集成构建一样。但是,在查看了原始git repo上的所有分支之后,我发现有两个分支与*/integration
说明符相匹配。看起来开发人员一定是错误地推送到了一个名称非常相似的新分支:我解决这个问题的方法是使用
refs/heads/integration
完整地指定分支,我假设简单地删除重复的违规分支也可以,但是通过精确地指定分支,我可以避免将来遇到同样的问题。我不确定这是你的问题的同一个原因,但这是对我有效的,希望在这种情况下对其他人也有效。
j8yoct9x2#
似乎可在最新Jenkins GIT plugin版本2.0中重现。
降级到1.x版本可能会解决这个问题。但是你也应该从旧的备份中恢复Jenkins配置,因为GIT插件1.x版本似乎不适用于新的2.0配置方案。
This thread建议启用“快速远程轮询”作为一种解决方案。在2.0版本中,我认为它被称为“使用工作区强制轮询”。
参考Jenkins问题:https://issues.jenkins-ci.org/browse/JENKINS-20767
x3naxklr3#
我今天遇到了同样的问题。当我添加“生成完成时删除工作区”发布任务时开始发生。我删除了该任务,似乎解决了问题。
a11xaf1n4#
我也遇到了同样的问题。
修复它的方法是注意到Git轮询日志看起来像这样:
注意
master
行没有写“alreadybuilt”,我构建了master
分支,这就解决了问题。ecbunoof5#
小心svn重定向,在我的情况下,我有同样的情况Jenkins无法检测,如果svn没有任何变化,总是触发.
问题是,在我的jenkins svn配置有这个url:
https://xxxx.yyy.es:443/svn/myproject/trunk及其重定向到
(我不知道为什么)
Jenkins必须配置上一个URL才能正确地检测svn的变化.
这是我的问题解决了。
http://antuansoft.blogspot.com.es/2014/10/jenkins-pool-smc-always-detect-changes.html
iyzzxitl6#
删除管道末端的清理步骤对我来说很有用:
cnh2zyt37#
还有另一种情况会发生这种情况,那就是仓库被转移了。我通过手动修改git URL解决了这个问题,git URL在该高速缓存文件中(Jenkins主文件夹中的/caches目录)