6

用于 hudson 的 git 插件运行良好。但是，构建脚本必须更新存储库中文件中的版本号，提交并推送回存储库。

当 Hudson 轮询 next 以检查更改时，它会进入无限循环，因为它将提交视为“更改”再次构建，它提交更改，因此再次构建，然后提交另一个更改，等等......你得到这个想法。

我停止了它，在每个存储库中运行了一个“git log”，并使用 git ls-tree HEAD 比较了最新的提交 ID 完全相同

此外，Hudson 运行此命令来检查更改：

git fetch +refs/heads/ :refs/remotes/origin/ git ls-tree HEAD

由于 Hudson 本身从其工作区存储库中推送了提交，并且显然 ls-tree 结果匹配，该命令如何确定存在更改？

似乎它必须在构建之前存储 ls-tree 的结果，并与没有最新提交的结果进行比较。啊。我可以尝试关闭提交以测试该理论。

无论如何，与其修复 Hudson 的 git 插件中的任何问题，我可以做些什么来确保在我的构建结束时 repos 是相同的并且 Hudson 会看到它。

如何解决这个问题？有任何想法吗？

韦恩

4

2 回答 2

5

您的构建系统不应与您的修订控制系统有任何写交互。它当然不应该自动推送这些更改。

您的构建系统可能会询问git（git describe例如通过 ）当前版本是什么。其他任何事情都是多余的并且容易出错。

您可能会考虑的另一件事是不轮询更改。这似乎是一种愚蠢的操作方式。（不可否认，我是一个重度 buildbot 用户，非常习惯于在事件中触发所有内容。）

正在轮询的 git 存储库知道它何时更改。它应该只告诉 CI 系统基于此立即开始构建。您可以更快地获得构建，并且由于它们都被触发，因此您不会无缘无故地让您的计算机坐在那里做大量工作。

于 2009-11-21T06:40:33.807 回答
3

而答案是！...

Git Hudson 插件已经被某人分叉以添加此功能，它运行良好。尽管如此，我还是不得不删除源代码并修复一些小问题。

现在它工作得很好。构建提交，Git 插件在没有循环的情况下推回存储库，认为它再次发生了变化。

精彩的！

如果其他人需要此功能，请在 Github.com 上查找 Hudson-GIT-Plugin 的 tickzoom 分支，但请检查是否已重新集成到主项目中。提交者说他有兴趣并计划合并这些分叉。

韦恩

于 2009-11-21T20:47:43.623 回答