2

如Jochen Wierum所述，我使用Build Pipeline Plugin和Jenkins Clone Workspace SCM Plug-in设置了 Jenkins 构建管道

这非常有用，但我有一个问题...... Clone Workspace SCM 插件只让您获得最新的（良好的）构建，因此管道图可能有点误导。如果我在版本号 4 中手动触发管道的第二阶段，但版本号 5 中的第一阶段已经发生，那么我触发的第二阶段实际上将使用版本号 5 中的构建工件。这可能是令人困惑和潜在的危险。

是否有更好的构建管道工作流程可以保证使用此特定构建集的特定上游构建工件？

我知道克隆工作区 SCM 插件仅存储最新的，但我认为可能有一种方法可以使用标准存档工件构建后操作来实现我的目标，以保留所有成功构建的存档。我只是不知道如何将其用作下一阶段的来源。

我已经找到了这个答案，但就我而言，我并没有尝试使用特定的修订版，而是使用前一个构建阶段的确切结果。例如，我的构建阶段工作之一可能是发布到暂存环境。为此，当我的早期阶段已经构建、运行测试等时，我不想一直回到源代码控制并从头开始构建。

4

2 回答 2

0

我使用构建参数来实现它。Jenkins 并不擅长让构建以正确的格式指定自己的参数（因为不同的参数有不同的格式），所以我在启动构建的“发布步骤”中使用了一些 Groovy：

import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable
build.addAction(new ParametersAction(new StringParameterValue('UPSTREAM_BUILD_NUMBER', '<SpecificBuildSelector><buildNumber>' + build.getNumber() + '</buildNumber></SpecificBuildSelector>')))

一旦从每个构建中记录下来，然后我使用 Copy Artifacts 插件将启动构建的工件复制到管道中的下一个作业中。您只需将新参数“UPSTREAM_BUILD_NUMBER”指定为复制工件插件的参数，然后您就可以访问整个管道中的相同文件，而无需担心新构建会在管道中进一步篡夺您的工件. 相同的文件只是从一个版本复制到另一个版本。如果这与指纹识别和构建管道插件相结合，您将获得一个持续部署管道，具有可听性以及在出现问题时部署先前构建的能力。

于 2013-09-24T15:19:33.650 回答
0

您可以创建一个包含更改集的虚拟文件并对其进行验证，以确保您在触发构建阶段时拥有所需的版本。有关如何执行此操作的更多详细信息。http://antagonisticpleiotropy.blogspot.com.au/2012/02/implementing-real-build-pipeline-with.html

于 2013-08-22T00:38:03.030 回答