我们有2个git存储库，Platform和US（我们还有其他地理特定的存储库，这就是它们被拆分的原因，但它们在这里并不一定相关）。美国依赖于平台。
我们正在使用git-flow（意味着新功能在他们自己的分支中，如feature/some-product，develop分支更稳定，代表QA就绪版本，master分支是稳定的和发布）。 （如果某个功能同时具有平台和美国部件，则每个部件中都会有一个名称相同的分支。）我们认为功能的Jenkins作业不应运行mvn deploy因为我们不想将它们发布到快照存储库并且可能不应该运行mvn install因为我们不希望不同的功能分支从Jenkins的本地存储库中获取它（我们不太确定）。我们相信他们应该只确保所有内容编译并且单元测试通过（mvn verify）。
这就是问题所在，，因为这些是单独的git存储库，我们对编译的jar（install或deploy）没有做任何事情，
mvn install}或如果我们只有一个积极开发的分支（或者我们使用的是subversion），这不会是一个问题。
我们有一些想法（以及每个想法）
8.1.0-SNAPSHOT-some-product）。
git submodule结帐平台和美国feature/some-product，并使用mvn verify --reactor或简单的pom文件，将顶级项目作为模块。
--reactor并不总是有效。mvn install。
feature/other-thing可能只在美国，所以在平台feature/some-product发布到Jenkins本地存储库后（可能与平台develop非常不同，美国feature/other-thing将是正常情况下构建，它会（我们认为）导致US feature/other-thing在错误的意义上失败（或传递！）（假设如果它是针对Platform develop编译的，它可能会得到不同的结果）。答案 0 :(得分：0)
我没有必要亲自解决这个问题....这是我对如何看待这个问题的想法：
如果你必须为两个分支只有一个工作（一个坏主意），你可以使用参数化构建插件传入文本字符串“US”或“Platform”，并在shell脚本中使用逻辑来检查相关回购的分支。
然而，这消除了使repo轮询启动构建的能力。您必须在cron上设置构建计划，无论如何都会获得新构建，即使repo没有更改（除非您的批处理/ shell脚本足够智能以检查更改）。
我认为没有任何理由没有两个单独的Jenkins工作，每个分支一个。
如果一个作业需要访问.jars（也就是构建工件），那么您总是可以从jenkins服务器上作业的“最新”URL引用任何其他jar的工件。确保作业指定了归档所需的工件。
答案 1 :(得分：0)
我最终解决这个问题的方法是使用maven版本插件。我必须确保所有模块都是顶级项目中的托管依赖项，但这可能是一个不同的问题。此外，我 am 确定这一点，即使美国项目与父项目相同，也需要明确声明其版本。
他们都调查git，但如果成功构建，平台作业也会触发US。
版本插件的工作方式需要您分两步完成。在作业中添加2“调用顶级Maven目标”，第二个是clean deploy。第一个与平台和美国略有不同。
平台：mvn versions:set -DnewVersion=yourBranchName-${project.version}。
美国：mvn versions:update-parent -DparentVersion=yourBranchName-${project.version} versions:set -DnewVersion=yourBranchName-${project.version}
如果分支仅存在于美国存储库中，那么显然不会使平台成为一个，而美国的分支与平台存在的命令相同。
我遇到的最后一个问题最初我的新版本是${project.version}-yourBranchName，但问题是该作业部署的存储库只接受了快照，因为版本没有在-SNAPSHOT结束时，它给出了错误代码400。