Многоконфигурационный / матричный конвейер сборки в Jenkins

Question

Какова современная лучшая практика для сборок с несколькими конфигурациями (с Jenkins)?

Я хочу поддерживать несколько веток и несколько конфигураций.

Например, для каждой версии V1, V2Программное обеспечение, которое я хочу, нацелено на платформы P1 и P2.

Нам удалось установить многоотраслевые декларативные конвейеры.Каждая сборка имеет собственный докер, поэтому его легко поддерживать на нескольких платформах.

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

С этим связано несколько проблем:

• Декларативный конвейер имеет больше ограничений по сценарию
• Сборки с несколькими конфигурациями не могут запускать декларативные конвейеры (даже с плагином параметризованных триггеров, который я получаю, "проект не компилируется").

Здесь также возникает вопрос, как использовать параметры в декларативных конвейерах?

Существует ли стратегия, которая дает лучшее из обоих миров, а именно:

• конвейер в виде кода
• отдельные индикаторы состояния
• ограниченное повторение?

Answer 1

Это частичный ответ.Я думаю, что другие с большим опытом смогут улучшить его.

Это в настоящее время не проверено.Я могу лаять не на то дерево.Пожалуйста, прокомментируйте или добавьте лучший ответ.

• Не используйте параметры конвейера, кроме случаев, когда вам нужен ввод пользователя

• Используйте гибрид сценариев идекларативный конвейер (см. также https://stackoverflow.com/a/46675227/1569204)

• Есть функция, которая объявляет конвейер на основе параметров: (см. также 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"
           }
         }
       }
    }

• Соответствующий код может быть перемещен в общую библиотеку (даже если вам не нужно делиться этим).

Answer 2

Я думаю, что самый чистый подход - это все это в конвейере, похожем на первый, который вы представили, единственное изменение, которое я здесь вижу, - это параллельное выполнение, так что вы на самом деле попытаетесь собрать / протестировать для обеих платформ.

Чтобы повторно использовать рабочее пространство предыдущего этапа, вы можете сделать: reuseNode true

Что-то похожее на этот поток, которое будет иметь параллельную сборку для платформ

pipeline { 
    agent 'docker'
    stages {
      stage('Common pre') { ... }
      stage('Build all platforms') {
      parallel {
        stage('Build, test and deploy for P1') {
            agent {
                dockerfile {
                   filename 'src/main/docker/Jenkins-P1.Dockerfile'
                   reuseNode true
                }
            }
            steps {
               sh buildit...
            }
        }
        stage('Build, test and deploy for P2') {
            agent {
                dockerfile {
                   filename 'src/main/docker/Jenkins-P2.Dockerfile'
                   reuseNode true
                }
            }
            steps {
               sh buildit...
            }
        }
      }
      }
      stage('Common post parallel') { ... }
    }
}