我有两个管道作业,其中作业1触发作业2。我希望job2与job1在同一个构建节点和工作区中运行。我做了以下几件事
job1:
node("linux-ubuntu") {
echo "Node: $env.NODE_NAME"
ws {
"$env.WORKSPACE/test"
}
build job: "Utilities/Playground/pass-node-job2",
parameters: [
string(name: "BUILD_NODE", value: env.NODE_NAME),
string(name: "WSPACE", value: "$env.WORKSPACE/test")
],
wait: true
}
job2:
properties([
parameters([
string(name: 'BUILD_NODE', defaultValue: "linux-ubuntu", description: 'If this job is triggered by another job, it will passed in its build node.'),
string(name: "WSPACE", defaultValue: env.WORKSPACE, description: "Workspace")
])
])
node(env.BUILD_NODE) {
sh "echo node: $env.BUILD_NODE"
sh "echo wspace: $env.WSPACE"
dir(env.WSPACE) {
sh "pwd && ls"
}
}
有没有更好的方法来做到这一点?我知道shared workspace plugin,但我不认为它支持管道。
编辑我知道这是一个简化的用例。为了提供上下文,我希望仍然能够单独运行job2。
在我的例子中,我使用了一个Git子模块。我有几个job2's
专门用于构建每个子模块,并有job1
用于克隆Git子模块存储库。因此,当job1
克隆存储库时,它将在某个构建节点和该构建节点内的工作区上执行。现在,当它触发job2
构建子模块时,我需要**job2
在job1
克隆Git子模块的同一构建节点和工作区中运行。
但是我不需要每次都运行job1
,并且仍然希望能够随时运行job2
**。
3条答案
按热度按时间y53ybaqx1#
看起来你试图避免多次克隆repo。如果需要花费太多时间,你可以使用这个技巧,然后在所有job 2示例中克隆repo,而不是篡改工作区:
我不确定你使用共享工作空间来完成任务的动机,所以我可能对上面的建议是错误的。不过,这只是在遇到具体问题时采取行动的一个例子。当然,你应该明白你所期望的任务结果是什么。顾名思义,工作区意味着与其作业紧密耦合,传递它似乎不是一个好主意-只需使用
wait:false
,当job 1在job 2结束之前重新启动时,一切都会崩溃。**Edit 1:**我在这里添加概念图是针对git repo 1中存在git子模块的情况:
6yjfywim2#
如果可行的话,作业不会触发作业2,因为你似乎知道脚本管道,你可以做的是构建管道,并将作业1作为管道中的第一阶段,作业2作为管道的第二阶段。这样,你可以写这样的东西:
如果这对你不起作用,你能提供关于上下文的细节吗(可能需要直接启动作业2,而不是依赖于作业1)
9vw9lbht3#
有一个选项叫做
customWorkspace
你可以阅读更多关于它here