Hudson 无限循环轮询 Git 存储库中的更改？
Hudson 的 git 插件运行良好。但是，构建脚本必须更新存储库中文件的版本号、提交并推送回存储库。
当 Hudson 轮询下一步以检查更改时，它会进入无限循环，因为它看到提交作为“更改”再次构建，从而提交更改，因此它再次构建，然后提交另一个更改，等等...你得到这个想法。
我停止了它，在每个存储库中运行了一个“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 插件中的任何问题，我可以做些什么来确保在构建结束时存储库是相同的，并且 Hudson 会看到它。
如何解决这个问题？有什么想法吗？
韦恩
The git plugin for hudson works well. However, the build script must update a version number in the files in the repository, commit, and push back to the repository.
When Hudson polls next to check for changes, it goes into an infinite loop because it sees that commit as a "change" builds again, which commits a change, so it builds again, then it commits another change, etc... You get the idea.
I stopped it, ran a "git log" in each repository and compared the latest commit ids are exactly the same using git ls-tree HEAD
Also, Hudson runs this command to check for changes:
git fetch +refs/heads/:refs/remotes/origin/
git ls-tree HEAD
Since Hudson itself pushed the commit from its workspace repository, and apparently the ls-tree results match, how can this command determine that there as been a change?
It seems that it must be storing the results of ls-tree prior to doing the build and comparing to that which won't have the latest commit. Ah. I can try turning off the commit to test that theory.
Anyway, rather than fix any issue in the git plugin for Hudson, what can I do to make sure at the end of my build that the repos are identical and that Hudson will see it so.
How to fix this? Any ideas?
Wayne
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的构建系统不应与修订控制系统进行任何写入交互。它肯定不应该自动推送这些更改。
您的构建系统可能询问 git（例如，通过
git描述）当前版本是什么。其他任何东西都是多余的并且容易出错。您可能要考虑的另一件事是不轮询更改。这似乎是一种愚蠢的操作方式。 （不可否认，我是一个重度 buildbot 用户，非常习惯于在事件上触发所有内容。）
正在轮询的 git 存储库知道它何时发生变化。它应该只是告诉 CI 系统立即基于此开始构建。您可以更快地获得构建，并且由于它们都被触发，因此您不会让计算机无缘无故地闲着做大量工作。
Your build system should not have any write interaction with your revision control system. It most certainly shouldn't push those changes automatically.
Your build system may ask git (via
git describe, for example) what the current revision is. Anything else is redundant and error prone.Another thing you may consider is not polling for changes. That seems like a silly way to operate. (Admittedly, I'm a heavy buildbot user quite accustomed to having everything be triggered on events.)
The git repo that's being polled knows when it changes. It should just tell the CI system to start a build immediately based on that. You get your builds sooner and since they're all triggered, you don't have your computers sitting around doing lots of work for no good reason.
答案是！...
Git Hudson 插件已经被某人分叉来添加这个功能，它运行良好。尽管如此，我还是必须删除源代码并修复一些小问题。
现在效果很好。构建提交，Git 插件推回存储库而不循环，认为它再次发生更改。
精彩的！
如果其他人需要此功能，请在 Github.com 上查找 Hudson-GIT-Plugin 的 tickzoom 分支，但检查是否已集成回主项目中。提交者表示他很感兴趣并计划合并这些分叉。
韦恩
And the answer is!...
The Git Hudson plugin was already forked by someone to add this feature it works well. Still, I had to pull down the source and fix a couple of minor issues.
Now it works beautifully. The build commits, and the Git plugin pushes back to the repository without looping, thinking it has again changed.
Wonderful!
If someone else needs this look for the tickzoom fork of the Hudson-GIT-Plugin on Github.com but check to see if has already been integrated back in to the main project. The committer said he was interested and planning on combining the forks.
Wayne