Multiconfiguration / matrix build pipeline in Jenkins

Question

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?

Answer 1

这是部分答案。我认为其他有更好经验的人将能够改进它。

目前尚未测试。我可能找错了树。请评论或添加更好的答案。

• 除非需要用户输入，否则不要使用管道参数

• 使用脚本化和声明式管道的混合（另请参阅/sf/answers/3267265921/）

• 有一个根据参数声明管道的函数：（另请参阅https://jenkins.io/doc/book/pipeline/shared-libraries/）

• 使用节点在管道中创建可见的指标（至少在蓝海中）

所以像下面这样：

    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"
           }
         }
       }
    }

• 相关代码可以移动到共享库（即使您实际上不需要共享它）。