Jenkins中的多配置/矩阵构建管道 [英] Multiconfiguration / matrix build pipeline in Jenkins
问题描述
对于多配置构建(使用Jenkins)，现代最佳实践是什么?
我想支持多个分支和多个配置.
例如，对于我要构建的软件的每个版本V1，V2， 平台P1和P2.
我们设法建立了多分支的声明式管道.每个构建都有自己的docker，因此可以轻松支持多个平台.
pipeline {
agent none
stages {
stage('Build, test and deploy for P1) {
agent {
dockerfile {
filename 'src/main/docker/Jenkins-P1.Dockerfile'
}
}
steps {
sh buildit...
}
}
stage('Build, test and deploy for P2) {
agent {
dockerfile {
filename 'src/main/docker/Jenkins-P2.Dockerfile'
}
}
steps {
sh buildit...
}
}
}
}
这提供了一个涵盖多个平台的工作，但每个平台没有单独的红色/蓝色状态. 有一个很好的论点，那就是，这无关紧要，因为除非该版本适用于所有平台，否则您不应发布.
但是，我希望每种配置都有单独的状态指示器.这表明我应该使用一种多配置版本，该版本会为每个配置触发一个参数化的版本，如下所示(以及链接的问题) :
pipeline {
parameters {
choice(name: 'Platform',choices: ['P1', 'P2'], description: 'Target OS platform', )
}
agent {
filename someMagicToGetDockerfilePathFromPlatform()
}
stages {
stage('Build, test and deploy for P1) {
steps {
sh buildit...
}
}
}
}
这有几个问题:
- 声明性管道对其脚本的编写方式有更多限制
- 多配置版本无法触发声明性管道(即使使用参数化的触发器插件，我也会得到项目不可生成"的信息.)
这也引出了一个问题，即声明性管道中的参数有什么用?
有没有一种可以兼顾两方面的策略，即:
- 管道作为代码
- 单独的状态指示器
- 重复次数有限?
这是部分答案.我认为其他具有更好经验的人将可以对此进行改进.
目前未经测试.我可能正在吠错树. 请发表评论或添加更好的答案.
-
除非需要用户输入，否则不要使用管道参数
-
使用脚本化和声明性管道的混合体 (另请参见 https://stackoverflow.com/a/46675227/1569204 )
-
具有一个根据参数声明管道的函数: (另请参见 https://jenkins.io/doc/book/book/pipeline/shared-库/)
-
使用节点在管道中创建可见的指示器(至少在蓝海中)
类似以下内容:
def build(string platform) {
switch(platform) {
case P1:
dockerFile = 'foo'
indicator = 'build for foo'
break
case P2:
dockerFile = 'bar'
indicator = 'build for bar'
break
}
pipeline {
agent {
dockerfile {
filename "$dockerFile"
}
node {
label "$indicator"
}
}
stages {
steps {
echo "build it"
}
}
}
}
- 相关代码可以移到共享库中(即使您实际上不需要共享).
What is modern best practice for multi-configuration builds (with Jenkins)?
I want to support multiple branches and multiple configurations.
For example for each version V1, V2 of the software I want builds targeting platforms P1 and P2.
We have managed to set up multi-branch declarative pipelines. Each build has its own docker so its easy to support multiple platforms.
pipeline {
agent none
stages {
stage('Build, test and deploy for P1) {
agent {
dockerfile {
filename 'src/main/docker/Jenkins-P1.Dockerfile'
}
}
steps {
sh buildit...
}
}
stage('Build, test and deploy for P2) {
agent {
dockerfile {
filename 'src/main/docker/Jenkins-P2.Dockerfile'
}
}
steps {
sh buildit...
}
}
}
}
This gives one job covering multiple platforms but there is no separate red/blue status for each platform. There is good argument that this does not matter as you should not release unless the build works for all platforms.
However, I would like a separate status indicator for each configuration. This suggests I should use a multi-configuration build which triggers a parameterised build for each configuration as below (and the linked question):
pipeline {
parameters {
choice(name: 'Platform',choices: ['P1', 'P2'], description: 'Target OS platform', )
}
agent {
filename someMagicToGetDockerfilePathFromPlatform()
}
stages {
stage('Build, test and deploy for P1) {
steps {
sh buildit...
}
}
}
}
There are several problems with this:
- A declarative pipeline has more constraints over how it is scripted
- Multi-configuration builds cannot trigger declarative pipelines (even with the parameterized triggers plugin I get "project is not buildable").
This also begs the question what use are parameters in declarative pipelines?
Is there a strategy that gives the best of both worlds i.e:
- pipeline as code
- separate status indicators
- limited repetition?
This is a partial answer. I think others with better experience will be able to improve on it.
This is currently untested. I may be barking up the wrong tree. Please comment or add a better answer.
Do not use pipeline parameters except where you need user input
Use a hybrid of a scripted and declarative pipeline (see also https://stackoverflow.com/a/46675227/1569204)
Have a function which declares a pipeline based on parameters: (see also https://jenkins.io/doc/book/pipeline/shared-libraries/)
Use nodes to create visible indicators in the pipeline (at least in blue ocean)
So something like the following:
def build(string platform) {
switch(platform) {
case P1:
dockerFile = 'foo'
indicator = 'build for foo'
break
case P2:
dockerFile = 'bar'
indicator = 'build for bar'
break
}
pipeline {
agent {
dockerfile {
filename "$dockerFile"
}
node {
label "$indicator"
}
}
stages {
steps {
echo "build it"
}
}
}
}
- The relevant code could be moved to a shared library (even if you don't actually need to share it).
这篇关于Jenkins中的多配置/矩阵构建管道的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
