4

我们正在努力改进我们的 Jenkins 设置。到目前为止，我们有两个目录：/plugins 和 /tests。

我们的项目是一个 Eclipse Plugins 的多模块项目。/tests 文件夹中的测试插件是片段项目，依赖于 /plugins 中相应的生产代码插件。

到目前为止，我们只有一项 Jenkins 工作，它检查了 /plugins 和 /tests，构建了所有这些并产生了 Surefire 结果等。

我们现在正在考虑将项目拆分为与我们提供的功能相对应的较小的工作。看来我们试图做到这一点的方式并不理想。

我们尝试了以下方法：

  1. 我们为核心功能创建了一个工作。该作业检查整个 /plugins 和 /tests 目录并仅构建该功能所包含的插件。该作业有一个单独的 pom.xml，它定义了核心工件并讲述了该功能中包含的模块。
  2. 我们为应该在功能插件上运行的测试创建了一个单独的作业。此作业使用来自核心作业的克隆工作区。该作业将在构建核心功能后运行。

我不知何故认为这不是最佳的。

  • 例如，只有核心作业可以更新签出的文件。如果只更新测试，核心功能不需要重新构建，但它会。
  • 一旦我有一个依赖于核心功能的功能，这个功能要么需要使用核心功能工作区的克隆，要么检查它自己的 /plugins 和 /tests 副本，这会导致膨胀。
  • 使用克隆的工作区，我无法更新我的来源。所以当我有一个特性依赖于另一个特性时，只有更新和构建核心特性才能完成这项工作。

我想我在这里遗漏了一些基本的东西。有人可以帮忙吗？肯定有一个更简单的方法。

编辑：如果一切正常，我将尝试制定我认为理想情况下会发生的情况：

  • 检查功能组件是否已更改（即可以对其进行更新）
  • 如果更改，构建功能
    • 如有必要，构建依赖特征（即检查 ob 对应的作业）
    • 构建功能本身
    • 如果构建成功，开始功能测试工作
    • 让我看看功能作业中的测试作业的结果

最后，项目工作应该

  • 做一个夜间构建
  • 查看 /plugins 和 /tests 的所有来源
  • 全部构建，全部测试，将结果发送到 Sonar

此外，如果不需要每晚构建，那将是整洁的，因为项目功能的构建和测试结果将结合在项目工作结果中。

这样的事情可能吗？

4

1 回答 1

2

从问题的结尾开始。我会保留一个单独的夜间工作，进行干净的签出（在签出之前摆脱任何生成的东西），从头开始构建所有内容，并运行所有测试。如果您没有进行干净的构建，则无法保证签入存储库的内容确实可以构建。

  • 检查功能组件是否已更改（即可以对其进行更新）
  • 如果更改，构建功能
    1. 如有必要，构建依赖特征（即检查 ob 对应的作业）
    2. 构建功能本身
    3. 如果构建成功，开始功能测试工作
    4. 让我看看功能作业中的测试作业的结果

[我假设 1 中的“依赖特征”是指 2 中的“特征”所需的东西。]

要做到这一点，我会说你有多个工作。

  • 每个单独的功能和每个简单构建该功能的依赖功能的工作。作业应该由（相关）功能的 SCM 更改启动。
  • 我不会将测试作业与编译作业分开。它允许成功编译的代码永远不会被测试。相反，我会依赖于 Jenkins 中的构建步骤失败的事实，它通常会中止进一步的构建步骤。

诀窍在于如何将所有这些连接在一起。

假设我们有一个名为F1的构建作业，它建立在 2 个依赖特性DF1.1和DF1.2 之上，每个特性都有自己的构建作业。

  • DF1.1和DF1.2都应该配置为触发F1的构建。
  • F1应配置为从最新成功的DF1.1和DF1.2构建中获取所需的工件。不幸的是，非常好的“克隆 SCM”插件在这里不会有太大帮助，因为它只是从以前的一项工作中提取的。也许其中一个工件发布器插件可能有用，或者您可能需要添加一些自定义构建步骤来放置/获取工件。
于 2012-05-04T14:31:04.673 回答