Continuous integration 如何让Hudson正确构建通过一次提交更改的多个模块

考虑一个有多个相互依赖的模块的Maven项目：比方说，三个jar模块a、B和C，它们是war模块Z的依赖项。我为每个模块都有一个单独的Hudson构建，因此只有更改过的模块才会被重新构建

我的问题是，如果我提交了一个同时更改模块a和模块Z的变更集，那么Z可能会在a之前生成并失败，在a完成并触发现在通过的Z的重建之前生成。允许构建由于与构建顺序有关的原因而经常失败，而不是“真正的”失败会使我们对真正的失败不敏感；我们最终忽略了已经合法破坏的构建，因为我们习惯于假设它最终会反转

我一直通过使用静默期、在上游构建运行时阻塞等方式来管理这一点。但实际上，我的构建比我给出的示例有更多的模块，其中许多模块需要一段时间来构建和测试。我还有一小群勤奋的开发人员，他们经常进行提交

这意味着我的jar模块在不断构建，很少为我的war模块构建留下空白。因此，战争不会频繁爆发，这意味着我们需要很长时间才能发现什么时候爆发了战争，也需要更长时间才能确定是哪一次变革爆发了战争

另外，构建的持续运行意味着，如果我提交了一个涉及jar a和B的更改，war文件Z可能会为jar a构建一次（构建速度很快），然后为jar B构建一次（耗时更长）。这使得很难理解给定提交的结果

我曾考虑过使用join插件，但这似乎每次都需要构建所有模块。因为我实际上有相当多的jar模块，我真的不想每次都构建它们，我只想构建为给定提交而更改的模块

有没有更好的方法来处理这个问题

---

谢谢

这一直是一个难题（我已经多次重写了这个答案！）

就技术解决方案而言，您需要等待多个不同作业的构建在开始运行之前停止运行。如果难以量化，就很难落实到位。我很有兴趣看看这篇文章中建议了什么技术解决方案

我想你必须看看为什么你的工作被运行，以及运行的频率。如果在您的WAR中有任何代码需要进行单元测试，您可以将其移出到它自己的模块中吗？这样，您就可以使用war每小时/30分钟只运行一次集成测试，而不必担心单个模块的位置和时间

您可能还想看看您的模块包含哪些内容。它们都必须是模块吗？您是否可以减少碎片—这可能有助于降低您试图计划的内容的复杂性：）

---

我理解并赞赏您为尽快获得尽可能多的测试所做的努力——但有时，如果代码不断流失，您所能做的就是进行冒烟测试。

我们现在考虑的方法是将一些Maven模块组合到单个Hudson作业中，而不是将模块映射到作业中

具体地说，如果war模块的依赖关系非常小，并且可以很快自行构建，那么在与war相同的作业中构建它们可以确保来自单个提交的所有代码都构建在一起，至少对于给定的war文件是如此

这确实会导致重复—我们有多个war文件使用相同的JAR，因此JAR基本上是为每次战争重建的，而不是只重建一次。但在实践中，JAR构建速度很快，这使得war文件在概念上更清晰

如果JAR需要一段时间来构建和测试，那么这就不那么吸引人了，因为组合的JAR+war作业将相当长，为我们提供了针对JAR中问题的长反馈循环。保持平衡很重要

---

因此，我的建议是：不要认为每个模块一个Hudson/Jenkins作业是最好的方法，也不要害怕在多个作业中重建相同的代码。

这是一个有趣的问题，但很难解决。我不认为我们的测试量过多，问题并不是真的缺少运行所有测试的时间，它更多的是协调依赖关系，以便将正确的版本构建在一起。我想你是对的，我们需要重新思考事物的结构。然而，我认为应该采取的角度可能是质疑Maven模块到Hudson项目的一对一映射是否正确