Jenkins 轮询 GitHub 应该足够聪明，不会重建相同的修订版……对吧？答案

【问题标题】：Jenkins polling GitHub should be smart enough not to rebuild the same revision... right?Jenkins 轮询 GitHub 应该足够聪明，不会重建相同的修订版……对吧？
【发布时间】：2014-09-18 04:18:40
【问题描述】：

我在 GitHub 中配置了一个 post-receive 挂钩，以按 here 的描述访问我的存储库的 Jenkins notifyCommit URL。

任何分支上的任何提交都会触发该钩子，该钩子会发送一个轮询事件。美好的。对功能分支进行更改，Jenkins 将进行轮询并注意到在作业的配置分支（主）上没有任何新内容可构建，对吧？

但显然不是，因为即使 Jenkins 工作投票日志显示：

[poll] Last Built Revision: Revision abc123 (origin/master)

推送到新分支origin/not-master 会触发构建，其日志显示：

Checking out Revision abc123 (origin/master)

因此，当 master 中没有任何变化时，它正在为 master 开始一个新的构建。这可能是如何配置作业的存储库和分支的问题吗？或者这就是预定轮询的工作方式？

【问题讨论】：

标签： github jenkins

【解决方案1】：

问题在于构建是由分支参数化的。我错误地假设通知只会构建由 master 的默认参数值指定的分支，或者它将构建通知所针对的任何构建。

通过将作业的分支修复为 master，构建触发器按预期工作。

【讨论】：

【解决方案2】：

由于我不知道的原因，Jenkins 似乎会跟踪它在工作工作区某处看到和构建的提交。如果您正在使用例如Workspace Cleanup plugin 在构建开始或结束时删除作业工作区，Jenkins 将失去对已构建内容的跟踪，并将启动新构建以恢复同步。

别这样了。如果您需要清理工作区，请使用 Git SCM“高级行为”下拉菜单并选择“结帐后清理”。这将使 Jenkins 运行“git clean”，如果作业使用 git，这是一种快速且安全的清理工作空间的方法。

【讨论】：