Jenkins - 构建循环

Question

解决方案

在配置分支以构建时删除通配符 *：

*/master 只是 master

---

此错误仅在 GIT SCM 与 JOB 相关时发生。

例如：我的日常工作是构建一个 Android 项目。首先我认为这是一个 cron 问题，目前我使用50 10 * * *，但我尝试过H 10 * * *没有任何成功。当时机成熟时，它总是构建作业（失败或成功）并将另一个作业排队......等等......

上次运行时间为 2015 年 5 月 22 日星期五上午 10:01:58 BRT；下一次运行时间为 2015 年 5 月 23 日星期六上午 10:01:58 BRT。

即使是带有参数的构建，它也每次都会将另一个作业排队。

所以它永远停留在构建循环中。

---

配置：

• 詹金斯版。1.614。
• Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-46-generic x86_64)
• GIT 客户端插件：1.17.1
• GIT 插件：2.3.5

---

控制台输出：

Started by an SCM change
Building in workspace .../jobs/PROJECT_NAME/workspace
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://GIT_ADDRESS/ # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from ssh://GIT_ADDRESS/
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress ssh://GIT_ADDRESS/ +refs/heads/master:refs/remotes/origin/master
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME
Checking out Revision e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6
 > git rev-list e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 # timeout=10
[Gradle] - Launching build.
[android] $ gradle clean build assemble
...

也许问题是这个？

 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME

---

构建循环：

---

作业配置：

---

全局配置：

---

Answer 1

查看控制台日志的开头部分，了解您手动启动的作业以及接下来自动排队的作业。

在控制台日志的开头，它给出了触发构建的原因，例如09:46:05 Started by an SCM change或16:06:58 Started by user Slav。请在问题中添加两个控制台日志的开头。

编辑：
现在我们知道 Jenkins 检测到 SCM 更改触发器，我们可以进一步推测导致此行为的原因是某种 SCM 提交后挂钩，或者另一个向 Jenkins 发送请求的脚本激活。

如果未启用 SCM 轮询，则提交后挂钩不应起作用，但其他任何方法都没有意义，因此让我们研究一下该途径。添加/pollingLog/到“由 SCM 更改”触发的内部版本号的内部版本 URL。有可能什么也找不到，但如果有的话，让我们确认一下。

接下来，如果可能，将 Jenkins 绑定到不同的 IP 地址和/或端口。如果存在触发二次构建的“流氓”脚本，它们将无法适应更改后的地址。

编辑2：
看起来git 客户端插件本身有一个错误，它在版本 1.6.2 中已修复。请检查您的 git 插件的版本。
资料来源：https://issues.jenkins-ci.org/browse/JENKINS-10767和https://issues.jenkins-ci.org/browse/JENKINS-20286