《破碎》本地存储库 - 我如何注意到?我怎样才能阻止它发生? [英] "Broken" Local Repository - how can I notice? How can I stop it from happening?
问题描述
我们构建服务器的本地存储库包含工件快照版本的不一致数据.即使为 mvn
设置了 -u
,这也会导致构建服务器加载旧的时间戳版本.
The Local Repository of our build server contained inconsistent data for a SNAPSHOT version of an artifact. This caused the build server to load an older timestamped version even if -u
was set for mvn
.
这种行为让我很担心.同事抱怨你不能相信 Maven 构建".我需要做点什么.
This behaviour worries me. Colleagues complained that you "cannot trust Maven builds". I need to do something about it.
当然,我可以为每个构建重新加载每个工件(基本上忽略本地存储库),但这会花费不必要的时间.
Of course, I could just reload every artifact for every build (essentially ignoring the Local Repository) but this would take unnecessarily long.
有没有办法确定本地存储库是否损坏"?
Is there a way to determine if a Local Repository is "broken"?
(请不要建议我们不要在构建服务器上使用快照——我们至少需要再使用一年.)
(Please do not advise us to not use SNAPSHOTs on the build server -- we need to do this for at least one more year.)
- 我们的构建服务器是 Quickbuild,但它应该没有太大关系,因为它只是检查代码然后调用 Maven.
- 不一致的原因在于以 -SNAPSHOT 结尾的文件(pom、jar 等)的年龄不同.它应该保留一份副本,但我没有,所以我不能提供更多细节.
- 本地存储库为大约 2000 个独立 Java 项目的所有构建共享.
推荐答案
作为评论中讨论的总结:您似乎有 2000 个独立的构建读取和安装到同一个本地 maven 存储库,构建服务器中的一个目录.那只是要求并发问题,因为本地maven仓库只是一个目录结构,缺乏处理目录结构并发更新的机制.
As a summary from discussion in the comments: you seem to have 2000 separate builds reading from and installing to the same local maven repository, a directory within your build server. That's just asking for concurrency issues, as local maven repository is just a directory structure, lacking any mechanism to handle concurrent updates to directory structure.
通常所做的是您已经构建了特定于作业的本地存储库和一个单独的存储库管理器来处理共享数据.所有创建的工件都将上传到存储库管理器,它也处理并发请求.如果我是你,这就是我的目标.
Usually what's being done is that you have build job-specific local repos and a separate repository manager dealing with shared data. All created artifacts would be uploaded to repository manager, which handles concurrent requests as well. That's what I'd aim for if I were you.
如果您坚持在本地文件级共享工件,那么这些至少应该只是从存储库管理器获取的工件,而不是本地生成的快照工件,因为这会导致并发问题.
If you insist on having local file-level sharing of artifacts, those should be at least only artifacts fetched from repo manager, not snapshot artifacts generated locally, as that will lead to concurrency issues.
这篇关于《破碎》本地存储库 - 我如何注意到?我怎样才能阻止它发生?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!