1

Hudson 提供了让 Maven 构建作业利用私有本地存储库的选项,或者使用 Maven 安装中的通用存储库,即与其他构建作业共享的一个。我觉得我们的构建应该使用私有本地存储库来确保它们是干净的构建。但是,这会导致性能问题,特别是在为每个作业下载所有依赖项的带宽方面——我们还将作业配置为从干净的“工作区”开始,这似乎会破坏私有 maven 存储库以及其余部分建造空间。

对于日常的持续集成构建,为每个构建作业选择是否使用私有本地 maven 存储库的优缺点是什么?与其他工作共享本地存储库有什么大不了的吗?

4

2 回答 2

1

解释詹金斯文档,你会使用private Maven repositoryif

  • 您最终会错误地成功构建,只是因为您在本地存储库中拥有所有依赖项,尽管事实上 POM 中的任何存储库都可能没有它们。
  • 您在尝试使用相同的本地存储库时遇到并发 Maven 进程的问题。

此外

使用此选项时,请考虑设置一个 Maven 工件管理器,这样您就不必经常访问远程 Maven 存储库。

您还可以探索scm 的 clean 选项(而不是工作区 clean),以避免此存储库遭到破坏。

于 2012-10-14T03:46:32.937 回答
0

我相信 Sonatype 建议使用本地 Nexus 实例,尽管他们自己的研究表明(2015 年软件供应链状况报告)到 Maven Central 的流量中只有不到 5% 来自此类存储库。

回到这个问题,假设您在构建服务器(例如 Jenkins)和 Nexus 之间有一个本地 Nexus 实例和高带宽连接(至少数十 Gbps),那么我可以看到使用私有本地存储库的一些缺点,在事实上,我认为构建性能的下降是一个合理的权衡。

上面说,我们到底在权衡什么?我们接受了一个小的性能损失,我们可以 100% 肯定地知道,独立、干净的构建与我们的本地 Nexus 实例作为代理工作。

后者很重要,因为考虑构建服务器上的本地存储库(可能在 jenkins 的用户主目录中)具有未缓存在 Nexus 中的人工制品(如果您开始针对 Maven Central 构建,这并非不可能) . 这种不同步的情况不是最理想的,因为如果 Nexus 与 Central 的上游连接暂时关闭,可能会出现 Nexus 中的缓存 TTL 设置意味着构建失败的情况。

最后,为了增加权衡的好处,我今天花了几个小时在共享的 Jenkins 用户 .m2/repository 中获得了一个人工制品。当天早些时候,与 Central 的上游连接在本地上下波动了数小时(企业环境中的神秘问题)。最后,我删除了整个共享 jenkins 用户 .m2/repository 以便从本地 Nexus 中检索所有内容。

值得考虑使用本地 .m2/repository(在 jenkins 用户主目录中)构建以及使用私有本地存储库(快速和较慢构建)进行构建。然而,在我的情况下,我可能只在第一种情况下选择私有本地存储库 - 如果我通过专注于低悬的成果来优化构建(例如拆分多模块构建),我可能能够接受惩罚。

于 2016-04-27T08:21:32.143 回答