5

采用这个基本的构建管道（带有 gradle 任务）：

  1. 编译/运行单元测试（gradle clean build）
  2. 集成测试（gradle integrationTest）
  3. 验收测试（gradle acceptTest）
  4. 部署（gradle myCustomDeployTask）

根据 Jez Humble 的“持续交付”一书，您应该只构建一次二进制文件。因此，在上述理论管道中，在第 1 步中，我们清理、编译和构建 WAR，在第 2 步中，我们运行集成测试（使用第 1 步中的编译代码），在第 3 步中，我们运行验收测试（使用已编译的步骤 1 中的代码），并在步骤 4 中部署 WAR（在步骤 1 中构建）。到目前为止，一切都很好。

我正在尝试在 Jenkins 中实现这个管道。因为每个作业都有自己的工作区，所以步骤 2、3 和 4 最终会重新编译代码并构建 WAR，这违反了只构建二进制文件一次的“持续交付”口头禅。

为了解决这个问题，我使用了“ Clone Workspace SCM ”Jenkins 插件，它将从第一个构建压缩工作区，并成为构建 2、3 和 4 的工作区的源。但是，gradle 仍然重新编译每个构建中的代码步骤，因为它显然使用文件的绝对路径来确定是否需要执行任务。由于插件将文件移动到了新的工作区，因此绝对路径发生了变化，这使得 gradle 认为它需要从头开始，而不是执行增量构建。

现在我们可以在 Jenkins 中共享工作空间，但这也令人不悦，因为可能会针对共享工作空间运行两个作业。

那么如何在坚持持续交付、Jenkins 和 Gradle 的最佳实践的同时使用 Jenkins 和 Gradle 实现上述管道呢？

4

2 回答 2

0

首先确保后面的目标（integrationTest 等）不依赖于编译。接下来，将第一个作业中生成的war文件发布为jenkins工件。然后使用复制工件插件之类的东西将战争文件复制到您的目标工作区。

于 2013-07-17T07:33:49.477 回答
0

我还没有尝试过，但是您可以尝试将以下内容添加到您的项目中：

build.onlyIf { ! Boolean.getBoolean('skip.build') }

使用参数运行 gradle，-Dskip.build=true构建任务将被跳过。

查看 gradle 文档中的Skipping Tasks 部分。

这类似于此 Gradle build without testing question 中的答案。

于 2013-07-18T17:59:02.213 回答