我已根据Build Pipeline Plugin所述的Jenkins Clone Workspace SCM Plug-in和Jochen Wierum设置了Jenkins构建管道
这非常有用,但我有一个问题......克隆工作区SCM插件只允许你获得最新的(好的)构建,因此管道图可能有点误导。如果我手动触发我的管道的第二阶段,例如,构建号码4,但是构建号5的第一阶段已经发生,那么我触发的第二阶段实际上将使用来自构建号5的构建技术。这可能是令人困惑且有潜在危险。
是否有更好的构建管道工作流程可以保证使用此特定构建集的特定上游构建工件?
我知道Clone Workspace SCM插件只存储最新的,但我认为可能有一种方法可以使用标准的归档工件构建后的操作来实现我的目标所有成功构建的灵感。我无法弄清楚如何将其作为下一阶段的来源。
我已经找到了this answer,但在我的情况下,我并没有尝试使用特定的修订,而是前一个构建阶段的确切结果。例如,我的一个构建阶段作业可能是发布到登台环境。为此,我不想一直回到源代码控制并从头开始构建,当时我的早期阶段已构建,运行测试等等。
答案 0 :(得分:0)
您可以创建一个包含更改集的虚拟文件,并在触发构建阶段时对其进行验证以确保您具有所需的版本。有关如何操作的更多详细信息。 http://antagonisticpleiotropy.blogspot.com.au/2012/02/implementing-real-build-pipeline-with.html
答案 1 :(得分:0)
我使用构建参数实现它。 Jenkins在让构建以正确的格式指定自己的参数方面不是很好(因为不同的参数有不同的格式),所以我在我的初始构建的“Post steps”中使用了一点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”指定为复制工件插件的参数,然后您就可以访问整个管道中的相同文件,而无需担心新版本会在管道中进一步篡改您的工件。相同的文件只是从一个构建复制到另一个构建。如果将其与指纹识别和构建管道插件结合使用,您将获得具有可听性的连续部署管道,并且如果出现问题,则能够部署先前的构建。