我们已经决定在我们的多存储库项目上设置一些持续集成过程。其思想是为所有目标环境自动构建,并运行回归测试。Jenkins似乎是一个全面的自由/开源软件解决方案,它提倡使用它的Pipeline插件。
在本例中,假设我们有库A,它是库B的必需依赖项。我们创建了一个自由项目build a ,它成功地克隆并编译了 a 。从文档和代码片段生成器中,我们启动了一个管道,其第一步是运行build a :node {
stage 'Build dependencies'
build 'build A'
//
stage 'Build executable'
git url: 'git@gitrepo:projectB', credentialsId: 'jenkins'
sh 'cmake -DPATH_TO_A=XXX ./'
// We do not know what to do then to use the built dependencies ?
// In particular, XXX should be replaced by a path to the header and binaries
// provided by A's build step.
}
我们无法找到如何在项目B的构建中使用这个构建的依赖项A。
您可以尝试将libA复制到libB中,以便您可以访问它。
详情请参考
https://www.cloudbees.com/blog/copying-artifacts-between-builds-jenkins-workflow使用文件夹符号
使用简单的文件夹符号:../project-A-name
从当前管道的工作区中获取其他工作应该是非常简单的。
你的脚本看起来像:
node {
stage 'Build dependencies'
def jobAName = "A"
build "build ${jobAName}"
stage 'Build executable'
git url: 'git@gitrepo:projectB', credentialsId: 'jenkins'
sh "cmake -DPATH_TO_A=../${jobAName}/yourartifact"
}
请注意,我用双引号替换了cmake
步骤的简单引号,以启用变量替换。
您还会注意到,我定义了一个变量来记录job A
的名称,但当然您可以直接在build
和sh
步骤中使用您的工作名称,但我发现重复常量容易出错。
使用复制工件插件
正如Tim在他的回答中提到的,你也可以使用复制工件插件将作业A复制到你当前的project B
管道中。您的管道看起来像这样:
node {
stage 'Build dependencies'
def jobAName = "A"
build "build ${jobAName}"
stage 'Build executable'
step ([$class: 'CopyArtifact', projectName: "${jobAName}", filter: 'target/yourartifact', target: '.']);
sh 'cmake -DPATH_TO_A=yourartifact'
}
同样,我使用了一个变量和双引号来替换变量。
在此步骤中,filter
参数将允许您在项目A工作空间中选择工件的相对路径,而target
参数将指定您希望在项目B工作空间中复制工件的位置。