Как настроить Jenkins 2 Pipeline, чтобы Jenkinsfile использовал предопределенную переменную

У меня есть несколько проектов, в которых используется Jenkinsfile, который практически одинаков. Единственная разница заключается в проекте git, который он должен проверить. Это вынуждает меня иметь один файл Jenkins для каждого проекта, хотя они могут использовать один и тот же файл:

node{
    def mvnHome = tool 'M3'
    def artifactId
    def pomVersion

    stage('Commit Stage'){
        echo 'Downloading from Git...'
        git branch: 'develop', credentialsId: 'xxx', url: 'https://bitbucket.org/xxx/yyy.git'
        echo 'Building project and generating Docker image...'
        sh "${mvnHome}/bin/mvn clean install docker:build -DskipTests"
    ...

Есть ли способ предварительно настроить местоположение git в качестве переменной во время создания задания, чтобы я мог повторно использовать один и тот же Jenkinsfile?

...
    stage('Commit Stage'){
        echo 'Downloading from Git...'
        git branch: 'develop', credentialsId: 'xxx', url: env.GIT_REPO_LOCATION
    ...

Я знаю, что могу настроить это так:

Этот проект параметризуется -> Строковый параметр -> GIT_REPO_LOCATION, по умолчанию = http://xxxx, и доступ к нему осуществляется с помощью env.GIT_REPO_LOCATION.

Недостатком является то, что пользователю предлагается начать сборку со значением по умолчанию или изменить его. Мне нужно, чтобы он был прозрачным для пользователя. Есть ли способ сделать это?


jenkins jenkins-pipeline continuous-delivery jenkins-2
person codependent    schedule 07.04.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете использовать подключаемый модуль Pipeline Shared Groovy Library иметь библиотеку, которую используют все ваши проекты, в репозитории git. В документации вы можете читайте об этом подробно.

Если у вас есть много конвейеров, которые в основном похожи, механизм глобальных переменных предоставляет удобный инструмент для создания DSL более высокого уровня, который фиксирует сходство. Например, все плагины Jenkins создаются и тестируются одинаково, поэтому мы можем написать шаг с именем buildPlugin:

// vars/buildPlugin.groovy
def call(body) {
    // evaluate the body block, and collect configuration into the object
    def config = [:]
    body.resolveStrategy = Closure.DELEGATE_FIRST
    body.delegate = config
    body()

    // now build, based on the configuration provided
    node {
        git url: "https://github.com/jenkinsci/${config.name}-plugin.git"
        sh "mvn install"
        mail to: "...", subject: "${config.name} plugin build", body: "..."
    }
}

Предполагая, что сценарий был загружен либо как глобальная общая библиотека, либо как общая библиотека на уровне папки, результирующий файл Jenkins будет значительно проще:

Jenkinsfile (сценарный конвейер)

buildPlugin {
    name = 'git'
}

В примере показано, как jenkinsfile передает имя = git в библиотеку. В настоящее время я использую аналогичную установку и очень доволен ею.

person herm    schedule 07.04.2017
comment
Спасибо за предложение, я попробую в ближайшие дни и вернусь с некоторыми отзывами. - person codependent; 10.04.2017
comment
Рассмотрите возможность использования многоветвевого конвейера. Тогда jenkins покажет отдельное задание для каждой ветки. Это более приятная визуализация, и вы можете начать ручную сборку для каждой ветки. - person herm; 10.04.2017

arrow_upward
0
arrow_downward

Вместо файла Jenkinsfile в каждом репозитории Git у вас может быть дополнительный репозиторий git, из которого вы получаете общий Jenkinsfile — это работает при использовании Задания конвейерного типа и выборе параметра Сценарий конвейера из SCM. . Таким образом, Дженкинс проверяет репозиторий, в котором у вас есть общий Jenkinsfile, прежде чем проверять репозиторий пользователя.

В случае, если задание может запускаться автоматически, вы можете создать хук после получения в каждом репозитории git, который вызывает Jenkins Pipeline с репозиторием в качестве параметра, чтобы пользователю не приходилось вручную запускать задание, вводя репо в качестве параметр (GIT_REPO_LOCATION).

В случае, если задание не может быть запущено автоматически, наименее раздражающий метод, который я могу придумать, — это использование параметра выбора со списком репозиториев вместо параметра String.

person xOUe    schedule 07.04.2017