场景:我们的开发团队使用Jenkins进行持续集成,而我们的一些代码是开源的,因此托管在GitHub.com上。
我们有相关GitHub存储库的本地镜像,并且我们的本地GitBlit服务器设置为定期轮询GitHub存储库以更新本地镜像。
这“有点起作用”;但问题情况是这样的:
1. 开发人员意识到他需要更改开源代码库,因此将更改推送到GitHub存储库,并更新闭源Git存储库中的子模块以指向新版本。 2. 然后,本地开发人员触发Jenkins上的自动构建,以便测试/验证更改在所有平台上是否有效。 3. Jenkins自动构建失败了,因为GitHub存储库的本地镜像尚未更新以反映原始更改,因此当Jenkins尝试在其各个工作区中更新子模块时,本地镜像无法识别闭源git存储库所指向的修订ID。
我们目前解决这个问题的方法是设置GitBlit更频繁地轮询GitHub,但我不喜欢这种解决方案,因为它会在互联网上造成更多的周期性/不必要的流量,并且仍然无法完全避免构建失败的可能性,例如,在开发人员推送更改后立即触发构建的情况下。
我们有相关GitHub存储库的本地镜像,并且我们的本地GitBlit服务器设置为定期轮询GitHub存储库以更新本地镜像。
这“有点起作用”;但问题情况是这样的:
1. 开发人员意识到他需要更改开源代码库,因此将更改推送到GitHub存储库,并更新闭源Git存储库中的子模块以指向新版本。 2. 然后,本地开发人员触发Jenkins上的自动构建,以便测试/验证更改在所有平台上是否有效。 3. Jenkins自动构建失败了,因为GitHub存储库的本地镜像尚未更新以反映原始更改,因此当Jenkins尝试在其各个工作区中更新子模块时,本地镜像无法识别闭源git存储库所指向的修订ID。
我们目前解决这个问题的方法是设置GitBlit更频繁地轮询GitHub,但我不喜欢这种解决方案,因为它会在互联网上造成更多的周期性/不必要的流量,并且仍然无法完全避免构建失败的可能性,例如,在开发人员推送更改后立即触发构建的情况下。
是否有已知的“最佳实践”解决方案可以自动为我们提供可靠的Jenkins构建行为,并避免不断轮询GitHub?