Jenkins：如何从 git 存储库构建多个顶级项目？

Jenkins: How To Build multiple top-level projects from a git repository?

提问by Martin Ahrer

I have a Git repository that contains a bunch of top-level maven projects (each sits in their own sub-directory with a pom.xml). Top-level here means that these projects sit in subdirectory directly underneath the repository root. All of these projects should remain in the same Git repository.

我有一个 Git 存储库，其中包含一堆顶级 maven 项目（每个项目都位于自己的带有 pom.xml 的子目录中）。这里的顶级意味着这些项目位于存储库根目录正下方的子目录中。所有这些项目都应该保留在同一个 Git 存储库中。

repo
+--- projectA
    +--- pom.xml

+--- projectB
    +--- pom.xml

They can/should be built by independent jenkins jobs. So we have a job for projectA and one for projectB.

它们可以/应该由独立的 jenkins 工作构建。所以我们有一个项目A的工作和一个项目B的工作。

Formerly with Subversion I was able to set up a Jenkins job (for each project) that would checkout only the project source and run a Maven build from the pom.xml.

以前使用 Subversion，我能够设置一个 Jenkins 作业（为每个项目），该作业将仅检出项目源并从 pom.xml 运行 Maven 构建。

With the Git model (probably the same with all DVCS) this changes and I'm not sure what is best practice. There are a few options that I see and from which none I really like:

使用 Git 模型（可能与所有 DVCS 相同）这会发生变化，我不确定什么是最佳实践。我看到了一些选项，但没有一个是我真正喜欢的：

1. Each Jenkins job is configuredto clone/pull the full Git repo and refers to the /pom.xml for the Maven build. So the job has all the code but builds only a slice of it.
2. Git offers Submodules (http://book.git-scm.com/5_submodules.html) which seem to be a bit tricky to handle (and can break easily)
3. Create a maven parent (aggregator that contains all of the projects) project that triggers each projects build (having a single jenkins job). This pom.xml contains elements for projectA and projectB.

1. 每个 Jenkins 作业都配置为克隆/拉取完整的 Git 存储库，并为 Maven 构建引用 /pom.xml。因此，该作业具有所有代码，但仅构建了其中的一部分。
2. Git 提供子模块 ( http://book.git-scm.com/5_submodules.html) 似乎有点难以处理（并且很容易损坏）
3. 创建一个 maven 父项（包含所有项目的聚合器）项目，该项目触发每个项目构建（具有单个 jenkins 作业）。此 pom.xml 包含 projectA 和 projectB 的元素。

Do you see any more useful approach for this (very typical setup). What is your experience? Any best practices?

你有没有看到任何更有用的方法（非常典型的设置）。你的经验是什么？任何最佳实践？

采纳答案by recampbell

I think you're working against the grain here. If these projects are released as a versioned unit, you should indeed create a parent POM. But you should probably only have a single CI job. If you want that build to go quickly, you can configure it to only build modules which have changed since the last build (advanced button in Build section - "Incremental build - only build changed modules"). You can also tell Jenkins to "Execute concurrent builds if necessary" to test multiple commits at once.

我认为你在这里反对粮食。如果这些项目作为版本单元发布，您确实应该创建一个父 POM。但是您可能应该只有一个 CI 工作。如果您希望该构建快速进行，您可以将其配置为仅构建自上次构建以来发生更改的模块（构建部分中的高级按钮 - “增量构建 - 仅构建更改的模块”）。您还可以告诉 Jenkins“如有必要，执行并发构建”以一次测试多个提交。

But I'm curious why you think you want multiple CI jobs? If you perceive that these two projects have different lifecycles, perhaps they should be versioned seperately and should therefore be in seperate git repositories. Don't conserve git repositories, they are cheap. In fact, the more the merrier in almost every case.

但我很好奇你为什么认为你想要多个 CI 工作？如果您认为这两个项目具有不同的生命周期，也许它们应该单独进行版本控制，因此应该在单独的 git 存储库中。不要保存 git 存储库，它们很便宜。事实上，几乎在所有情况下，越多越好。

Usually, you want a given pom to produce a single artifact. Aggregator poms are useful for breaking up parts of a larger artifact into submodules, but only if those submodules aren't released on their own.

通常，您希望给定的 pom 生成单个工件。聚合器 poms 可用于将较大工件的一部分分解为子模块，但前提是这些子模块不单独发布。

回答by user133536

@recampbell, I have the same problem. We have several interrelated projects in a single Hg repository.

@recampbell，我有同样的问题。我们在一个 Hg 存储库中有几个相互关联的项目。

That way we know exactly under which version (hg version number), each other compile. When I say exactly, I mean I can verify it is binary identical.

这样我们就知道在哪个版本（hg 版本号）下，彼此编译。当我确切地说时，我的意思是我可以验证它是二进制相同的。

Using release numbers is too coarse grained. For example today I found a bug that was reproducible only under hg version 3367 but not in hg version 3368. Using multiple hg repos that would have been non reproducible, since there are several commits in each of the projects every day, and therefore it is impossible to determine exactly which version of each individual project was used, only the hg version is the correct one to use (using bisect to find the bug).

使用版本号太粗粒度了。例如，今天我发现了一个错误，它只能在 hg 3367 版中重现，而在 hg 3368 版中不能重现。使用多个无法重现的 hg 存储库，因为每个项目每天都有几次提交，因此它是无法准确确定使用了每个单独项目的哪个版本，只有 hg 版本才是正确使用的版本（使用 bisect 查找错误）。

It turned out we changed the client database driver version in one of the subprojects and that made our automated dao-generation fail with a NPE. The driver of course if a release version which we don't write, we simply use the one provided by the vendor. It would have taken us several days debugging this, but since we use Jenkins to build every hour, we knew there were between 10 to 20 commits to search, and only 3 or 4 touched the dao-generator, so it was an easy task.

事实证明，我们更改了其中一个子项目中的客户端数据库驱动程序版本，这导致我们的自动 dao 生成因 NPE 失败。驱动程序当然如果是我们不写的发布版本，我们就简单地使用供应商提供的版本。调试这个需要几天时间，但由于我们每小时使用 Jenkins 构建，我们知道有 10 到 20 个提交要搜索，只有 3 或 4 个接触到 dao 生成器，所以这是一项简单的任务。

Having mixed versions of every project would have been a pain in the lower rear back, since we would have several different dao-generator-3.1.2.jar which would be a little bit different one from the other (unless you expect us to change the version numbers after every commit, or if there is some configuration in Jenkins/maven/whatever that does this automatically? that would be great...).

将每个项目的混合版本都放在后背上会很痛苦，因为我们会有几个不同的 dao-generator-3.1.2.jar，其中的一个与另一个略有不同（除非你希望我们改变每次提交后的版本号，或者如果 Jenkins/maven/任何自动执行此操作的配置中有一些配置？那会很棒......）。

回答by Stephen

Well there is the best practise of not repeating yourself. So having a super POM would be good from that stand point.

嗯，最好的做法是不要重复自己。所以从这个角度来看，拥有一个超级 POM 会很好。

Id probably go with option 1. Disk space is usually cheap.

我可能会选择选项 1。磁盘空间通常很便宜。

But 3 would make it easier to deploy to new systems, without setting up Jenkins again.

但是 3 可以更轻松地部署到新系统，而无需再次设置 Jenkins。