不应该使用 Artifactory 来捕获 Jenkins 生成的构建工件吗？

Posted 2023-03-06

【中文标题】不应该使用 Artifactory 来捕获 Jenkins 生成的构建工件吗？

【英文标题】：Should Artifactory NOT be used to capture the build artifacts that Jenkins produces?

【发布时间】：2012-08-09 21:01:36

【问题描述】：

我们使用 Jenkins 来运行持续集成构建。这些构建的输出可能是一个 EAR 文件、一个 WAR 文件或一组经过 TAR 处理并部署到上游环境的文件。

到目前为止，我们已经使用 Jenkins 来管理生成的工件。但是，我们在内部部署了 Artifactory。利用 Artifactory 捕获生成的工件会是一个坏主意吗？如果是这样，为什么？例如，Artifactory 是否仅用于保存具有可以在构建时使用 Maven 拉入项目中的版本的 JAR，而不是用于捕获持续集成工具使用的工件？

【参考方案1】：

Artifactory（或任何二进制存储库管理器）应该与您的 CI 服务器一起使用。 甚至还有plugin。

维护二进制存储库管理器优于其他解决方案（网络共享、SCM）的原因很明显：

为二进制文件量身定制。 高效。 安全。 用于分发的单一可控网关。

还有更多。

所以您使用二进制存储库管理器来控制您的依赖关系并解决您的工件，但为什么要停在那里呢？你的整个周期都有二进制文件：

构建环境的二进制文件。 构建过程所需的二进制文件。 CI 期间生成的二进制文件。 应分发的已发布二进制文件。

二进制存储库管理器是保存它们的最安全、高效和自然的地方。将所有二进制文件保存在一个地方意味着更少的维护和更高的构建可重复性。

【参考方案2】：

我不这么认为。下图来自 sonatype 网站：

演示您的 Maven 存储库管理器如何成为您的部署过程的平台

【讨论】：

您能否提供一个链接，说明您在哪里检索到此图表？

@DavidV 我以为它来自 Sonatype 网站，但再也找不到那里的图表了。

感谢您告诉我。这是一个非常有趣的概念，我希望从原始来源获得更多关于它的信息。

@DavidV 明白了。我计划研究 Nexus 对 RPM 包的支持，这对我的 Chef 设置非常有用。见：blog.sonatype.com/2012/09/…