以这个基本的构建管道(带有 gradle 任务)为例:
根据Jez Humble的“连续交付”书，您只应构建一次二进制文件。因此，在上述理论流程中，我们在步骤1中清理，编译和构建WAR，在步骤2中运行集成测试(使用步骤1中的编译代码)，在步骤3中运行验收测试(使用编译后的代码)步骤1中的代码)，然后在步骤4中部署WAR(在步骤1中构建)。到现在为止还挺好。
我正在尝试在 Jenkins (Jenkins)中实现此管道。因为每个作业都有自己的工作区，所以步骤2、3和4最终会重新编译代码并构建WAR，这违反了“连续交付”的要求，即仅构建二进制文件一次。
为了解决这个问题，我使用了“Clone Workspace SCM” Jenkins插件，它将从第一个版本开始压缩工作空间，并成为第2、3和4个版本的工作空间的源。但是，gradle仍会在每个步骤中重新编译代码，因为it apparently uses the absolute path of the files to determine if a task needs to be executed。由于插件将文件移动到新的工作空间，因此绝对路径已更改，这使gradle认为它需要从头开始，而不是执行增量构建。
现在，我们可以在Jenkins中共享工作空间，但是由于在共享工作空间上运行两个作业的可能性，这也让人感到不满意。
因此，在遵循持续交付，Jenkins和Gradle的最佳实践的同时，如何使用Jenkins和Gradle来实现上述管道？
最佳答案
首先确保后面的目标(integrationTest 等)不依赖于编译。接下来，将第一个作业中生成的 war 文件发布为 jenkins 工件。然后使用类似 copy artifact plugin 的东西将 war 文件复制到您的目标工作区。
关于Jenkins 使用增量 Gradle 构建构建管道，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17687057/