Параметризация задания Jenkins с версиями нескольких вышестоящих заданий

Question

Мне нужно создать конвейер сборки, который состоит из нескольких проектов, которые зависят друг от друга. Вот упрощенная иллюстрация:

SVN A --> build A --\
                    |
SVN B --> build B --|
                    |
SVN C ----------------> build C

Конвейер должен работать так, чтобы при внесении изменений в SVN-репозиторий любого из проектов этот проект создавался автоматически. Кроме того, после того, как A или B был построен, он запускает здание C.

Каждая сборка создает двоичные файлы с уникальным номером версии ("XYBuildNumber"), и C должен получить в качестве параметра номера версий как A, так и B, чтобы C мог быть построен с использованием этих версий. По умолчанию C должен использовать последние успешные сборки A и B, но также должна быть возможность инициировать C вручную, используя более старую версию A или B (например, если мы хотим развернуть более старую версию одного из проектов).

Создание конвейера, подобного этому, может быть выполнено в готовом виде на Go, но моя компания считает это слишком дорогим. (Обновление 2014-02-27: Go не является открытым исходным кодом и бесплатен!) Так что теперь я пытаюсь выяснить, как добиться того же, используя Jenkins, но пока не нашел пути. Я нашел только инструкции по созданию простых линейных и ромбовидных конвейеров в Jenkins, но не конвейеров с несколькими независимыми проектами.

Answer 1

С помощью плагина копирования артефактов можно передавать номера версий из исходных заданий в последующие. Запишите номер версии в файл в исходном задании, заархивируйте его, а затем используйте этот плагин, чтобы прочитать его в последующем задании. Выберите сборку Upstream, которая запустила этот проект, и используйте "Последняя успешная сборка" в качестве альтернативных вариантов в конфигурации плагина.

Для получения дополнительной информации см. Взаимозависимые конвейеры сборки с Jenkins.

Answer 2

Мы используем build-pipe-plugin для чего-то похожего, и мы предоставляем простой сценарий, который хранит информацию о сборке во время выполнения для передачи в последующие проекты:

Немного многословно, потому что мы включаем информацию SVN для последующих сборок:

import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable

def workspace = build.getWorkspace()

def ant = new AntBuilder() 
ant.exec(executable: "svn", outputproperty: "output", dir: workspace){ 
    arg(line: "info") 
}
svnInfo = ant.project.getProperty("output")
print svnInfo 

def pattern = /Last\s+Changed\s+Author:\s+(\w+)/ 
def matcher = (svnInfo =~ pattern)
def user = matcher[0][1]

def langs = new XmlParser().parseText(build.getParent().getWorkspace().child('pom.xml').readToString())
def appVer = langs.properties.release.text()
def artifactId = langs.artifactId.text()

def params = [
new StringParameterValue('PL_SVN_REVISION', build.getEnvVars()['SVN_REVISION']),
new StringParameterValue('PL_BUILD_NUMBER', build.getEnvVars()['BUILD_NUMBER']),
new StringParameterValue('PL_APP_NAME', 'FooApp'),
new StringParameterValue('PL_COMMITTER_NAME',user ),
new StringParameterValue('PL_APP_VERSION',appVer),
new StringParameterValue('PL_ARTIFACT_ID',artifactId) 
]
build.addAction(new ParametersAction(params))

Тогда в последующей сборке они должны быть доступны примерно так:

Пример 1. Установка ввода имени сборки:

#${BUILD_NUMBER} - ${ENV,var="PL_APP_NAME"} - ${ENV,var="PL_APP_VERSION"} - ${ENV,var="PL_SVN_REVISION"}

Пример 2. Вызов целевого ввода Ant:

deploy
  -Denvironment=ONT-base
  -DWAR-LOCATION=%war-repo%/%PL_APP_NAME%/%PL_BUILD_NUMBER%-%PL_SVN_REVISION%/
  -DWAR-NAME=%PL_ARTIFACT_ID%-%PL_APP_VERSION%.%PL_BUILD_NUMBER%-%PL_SVN_REVISION%.war

---

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