我们有一个包含多个“工作”的 CloudBees 项目。其中一些工作对应于独立更新的独立 Google 项目。
我们的问题是所有更新都转到同一个快照存储库，所以当两个开发人员 A 和 B 在同一个项目上工作并且 A 正在推送他的更改时，B 得到的是最新版本，而不是他的本地版本想要。
理想情况下，我们希望每个 Google 项目都有一个快照存储库，这样它们就不会相互重叠。
如何在同一个 CloudBees 项目中创建不同的快照存储库并将它们关联到不同的项目？
【问题讨论】：
如果您真的想为不同的项目使用不同的快照存储库，那么您需要为每个作业使用“私有本地存储库”功能，以确保作业从它们自己的快照存储库中提取依赖项。
此外，您需要为每个作业提供单独的 settings.xml，否则它们无论如何都会从同一个远程存储库中提取依赖项。
然后，您需要使用 Forge 存储库屏幕在 CloudBees 服务中创建一个单独的 Maven WebDAV 存储库。请注意，如果您处于免费层，您可能会受到 Maven WebDAV 存储库数量的限制……您可能会作弊！通过告诉 settings.xml 存储库路径实际上是路径的子路径，例如https://user1650693.forge.cloudbees.com/repositories/snapshot/project1 和 https://user1650693.forge.cloudbees.com/repositories/snapshot/project2 而不是 https://user1650693.forge.cloudbees.com/repositories/snapshot
这实质上意味着 project1 和 project2 将看到完全独立的远程存储库。
所有这一切都代表你做了大量工作......而且管理起来很痛苦......当你在 Maven 中做很多工作时，大声尖叫 em> 你做错了！
也许您需要停下来想一想您在哪里调用了 Maven 反模式并远离该反模式。
我经常看到的一种反模式是，当您不了解自己在做什么时，运行构建超过 verify 阶段。
一般来说，我建议 CI 系统永远不要为非发布版本运行 deploy，因为它会困扰开发人员... [解决方法是运行 deploy，但运行到单独的 -SNAPSHOT 存储库，该存储库仅CI系统使用]
这就是为什么我也赞成只在 CI 系统上达到 verify，就像你达到 install 一样，你需要每个作业都有自己的私有 maven 存储库......虽然有时你需要走那么远，将工作零碎地分解。
经验法则是，开发人员的机器应该具有开发人员构建的依赖项，而不是在 Maven 刷新时随机更新 - SNAPSHOT 每次您在 settings.xml 间隔中配置的任何内容
【讨论】：
verify 将起作用，因为它是在工件被打包并附加到反应器的package 阶段之后。唯一的问题是有些人使用不了解 Maven 工作原理的插件，而那些不幸的人不得不去install... 解决方案：修复 borked 插件 ;-)
build-helper:attach-artifact 以获取有关从插件中附加工件的示例代码
从 maven 的角度来看，在您的场景中，如果 B 不想获得“最后一个稳定版本”，则不应依赖 A SNAPSHOT。
您还可以使用“私有本地存储库”高级选项“隔离您的 jenkins 作业 maven local-repository”，这样 B 将只能看到 B 的最后一个公开部署的版本，而不是最后一个构建的版本
【讨论】：