Jenkins Multi-Branch Pipeline включает еще один сценарий в локальный файл Jenkins

Мы только начинаем использовать Jenkins Multi-branch pipelines. Мне нравится идея, что Jenkins автоматически создает новое задание Jenkins при создании новой ветки. Он гарантирует, что вся выпускаемая разработка ведется в Jenkins. У нас есть около 40 или 50 проектов, которые разветвляются почти для каждого выпуска, и создание этих 40 или около того заданий каждый раз, когда мы разветвляемся, чревато ошибками.

Однако я вижу в Jenkins два типа конвейерных сборок:

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

  • Сборки Multi-Branch Pipeline: Jenkins автоматически создаст для вас новое задание Jenkins при создании новой ветки. Это означает, что нам больше не нужно создавать десятки новых проектов Jenkins при возникновении новой ветки. Однако похоже, что Jenkinsfile должен находиться в корне проекта. Если вы внесете базовые изменения в процедуру сборки, вам придется обновить все проекты Jenkins.

Я хотел бы иметь возможность использовать сборку Multi-Branch Pipeline, но я хочу либо указать, где извлечь Jenkinsfile из нашего репозитория, либо включить мастер Jenkinsfile из URL-адреса репозитория.

Есть ли способ сделать это с помощью Jenkins Multi-branch pipelines?


person David W.    schedule 18.08.2016    source источник


Ответы (1)


Если у вас есть общая логика сборки для разных репозиториев, вы можете переместить большую часть логики конвейера в отдельный Groovy-скрипт. Затем на этот сценарий можно будет ссылаться в любом файле Jenkins. Это можно сделать, проверив еще одну проверку репо, в котором находится Groovy-скрипт, в другой каталог, а затем выполните стандартную загрузку Groovy, или, вероятно, лучшим подходом было бы сохранить его как Groovy-скрипт в библиотеке Jenkins Global Script Library. - который по сути является автономным репозиторием git в Jenkins (см. https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/README.md для получения дополнительной информации).

У нас было аналогичное требование, и мы создали глобальный метод Groovy в сценарии, который поддерживался в Git и развертывался в библиотеке глобальных сценариев Jenkins в каталоге / vars / при его изменении: например, сценарий scriptName.groovy имеет

def someMethod(){
   //some build logic
   stage 'Some Stage'
   node(){
    //do something
   }
}

Таким образом, общая функция может быть вызвана в любом файле Jenkins через

scriptName.methodName()
person GCDev    schedule 25.08.2016
comment
Да, посмотрите этот ответ для получения дополнительных примеров. - person rbellamy; 30.03.2017
comment
Кроме того, если вы дадите вызов имени метода, вы сможете вызвать его с именем файла сценария. Итак, если у вас есть файл /vars/scriptName.groovy, вы можете использовать его как scriptName () - person 0neel; 31.05.2017