场景：我们的开发团队使用Jenkins进行持续集成，我们的一些代码是开源的，因此托管在GitHub.com上。
我们有相关GitHub存储库的本地镜像，我们的本地GitBlit服务器设置为定期轮询GitHub储存库以更新本地镜像。
这种"作品"；但问题是：
- 开发人员意识到他需要对开源代码库进行更改，因此他将更改推送到GitHub存储库，并更新我们的闭源Git存储库中的子模块，以指向新版本
- 然后，本地开发人员在Jenkins上触发一个自动构建，这样他就可以测试/验证这些更改是否适用于所有平台
- Jenkins的自动构建失败了，因为GitHub存储库的本地镜像尚未更新以反映原始版本，所以当Jenkins试图更新其各个工作区中的子模块时，本地镜像无法识别闭源git存储库所指向的修订ID
我们目前解决这个问题的方法是将GitBlit设置为更频繁地轮询GitHub，但我不喜欢将其作为一种解决方案，因为它会导致互联网上更周期/不必要的流量，并且仍然不能完全避免构建失败的可能性，例如，在开发人员推送更改，然后立即触发构建的情况下。
对于这个问题，是否有一个已知的"最佳实践"解决方案可以自动为我们提供可靠的Jenkins构建行为，并避免不断轮询GitHub？
您可以使用Github webhook通知本地基础设施以下事件：
- 存储库被推送到
- 打开拉取请求
- GitHub Pages网站已建成
- 团队中添加了新成员
请注意，这将最大限度地减少延迟，但在某些情况下，例如网络问题或Github基础设施部分中断，它仍然可能使您的构建失败。
将Jenkins自动构建设置为在构建之前更新本地镜像可能是唯一安全的解决方案。
我认为这里最好的解决方案是使用真正的Git存储库镜像，而不是尝试滚动自己的镜像。如果不能访问webhook(假设你没有GitHub存储库(，你能做的最好的事情就是轮询。
有一些开源解决方案(脑海中浮现的是Artifactory和Nexus(可以镜像Git存储库并提供缓存功能。我想你会发现，这些镜像比按一定间隔更新的脚本要可靠得多。此外，我认为他们可以做一些事情，比如当用户试图提取时，对上游回购进行快速哈希验证，这样他们就知道它们是否过时了(并会立即更新以提供正确的版本(。