Как мне динамически запускать нисходящие сборки в jenkins?
Мы хотим динамически запускать интеграционные тесты в различных последующих сборках в jenkins. У нас есть проект параметризованного интеграционного теста, который принимает имя теста в качестве параметра. Мы динамически определяем имена наших тестов из репозитория git.
У нас есть родительский проект, который использует jenkins-cli для запуска сборки проекта интеграции для каждого теста, найденного в исходном коде. Родительский проект и проект интеграции связаны через соответствующие отпечатки пальцев.
Проблема с этим подходом состоит в том, что совокупные результаты теста не работают. Я думаю, что проблема заключается в том, что "нисходящие" интеграционные тесты запускаются через jenkins-cli, поэтому jenkins не осознает, что они являются нисходящими.
Я посмотрел на многие плагины Jenkins, чтобы попытаться заставить это работать. Плагины Join и Parameterized Trigger не помогают, потому что они ожидают создания статического списка проектов. Фабрики параметров, доступные для параметризованного триггера, также не будут работать, потому что нет фабрики для создания произвольного списка параметров. Плагин Log Trigger не будет работать.
Плагин Groovy Postbuild выглядит так, как будто он должен работать, но я не мог понять, как запустить сборку из него.
6 ответов
def job = hudson.model.Hudson.instance.getJob("job")
def params = new StringParameterValue('PARAMTEST', "somestring")
def paramsAction = new ParametersAction(params)
def cause = new hudson.model.Cause.UpstreamCause(currentBuild)
def causeAction = new hudson.model.CauseAction(cause)
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction)
Это то, что, наконец, сработало для меня.
ПРИМЕЧАНИЕ. Плагин Pipeline должен сделать этот вопрос спорным, но у меня не было возможности обновить нашу инфраструктуру.
Чтобы запустить последующее задание без параметров:
job = manager.hudson.getItem(name)
cause = new hudson.model.Cause.UpstreamCause(manager.build)
causeAction = new hudson.model.CauseAction(cause)
manager.hudson.queue.schedule(job, 0, causeAction)
Чтобы начать последующую работу с параметрами, вы должны добавить ParametersAction, предполагать Job1 имеет параметры A а также C который по умолчанию "B" и "D" соответственно. То есть:
A == "B"
C == "D"
предполагать Job2 имеет те же параметры A и B, но также принимает параметр E который по умолчанию "F". Следующий пост пост скрипт в Job1 будет копировать его A а также C параметры и установить параметр E к объединению Aи Cценности:
params = []
val = ''
manager.build.properties.actions.each {
if (it instanceof hudson.model.ParametersAction) {
it.parameters.each {
value = it.createVariableResolver(manager.build).resolve(it.name)
params += it
val += value
}
}
}
params += new hudson.model.StringParameterValue('E', val)
paramsAction = new hudson.model.ParametersAction(params)
jobName = 'Job2'
job = manager.hudson.getItem(jobName)
cause = new hudson.model.Cause.UpstreamCause(manager.build)
causeAction = new hudson.model.CauseAction(cause)
def waitingItem = manager.hudson.queue.schedule(job, 0, causeAction, paramsAction)
def childFuture = waitingItem.getFuture()
def childBuild = childFuture.get()
hudson.plugins.parameterizedtrigger.BuildInfoExporterAction.addBuildInfoExporterAction(
manager.build, childProjectName, childBuild.number, childBuild.result
)
Вы должны добавить $JENKINS_HOME/plugins/parameterized-trigger/WEB-INF/classes к плагину Groovy Postbuild Additional groovy classpath,
Выполнить этот Groovy скрипт
import hudson.model.*
import jenkins.model.*
def build = Thread.currentThread().executable
def jobPattern = "PUTHEREYOURJOBNAME"
def matchedJobs = Jenkins.instance.items.findAll { job ->
job.name =~ /$jobPattern/
}
matchedJobs.each { job ->
println "Scheduling job name is: ${job.name}"
job.scheduleBuild(1, new Cause.UpstreamCause(build), new ParametersAction([ new StringParameterValue("PROPERTY1", "PROPERTY1VALUE"),new StringParameterValue("PROPERTY2", "PROPERTY2VALUE")]))
}
Если вам не нужно передавать свойства из одной сборки в другую, просто удалите действие ParametersAction.
Запланированная вами сборка будет иметь ту же "причину", что и ваша первоначальная сборка. Это хороший способ пройти в "Изменения". Если вам это не нужно, просто не используйте новый Cause.UpstreamCause(build) в вызове функции
Поскольку вы уже запускаете нижестоящие задания динамически, как насчет того, чтобы дождаться их завершения и скопировать файлы результатов теста (я бы заархивировал их для последующих заданий, а затем просто загрузил бы артефакты сборки) в родительское рабочее пространство. Вам может потребоваться объединить файлы вручную, в зависимости от того, может ли плагин Test работать с несколькими страницами результатов теста. На этапе пост-сборки родительских заданий настройте соответствующий тестовый плагин.
Это сработало для меня, используя "Выполнить систему Groovy скрипт"
import hudson.model.*
def currentBuild = Thread.currentThread().executable
def job = hudson.model.Hudson.instance.getJob("jobname")
def params = new StringParameterValue('paramname', "somestring")
def paramsAction = new ParametersAction(params)
def cause = new hudson.model.Cause.UpstreamCause(currentBuild)
def causeAction = new hudson.model.CauseAction(cause)
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction)
Используя плагин Groovy Postbuild, может быть, что-то вроде этого будет работать (не пробовал)
def job = hudson.getItem(jobname)
hudson.queue.schedule(job)
Я на самом деле удивлен, что если вы дактилоскопируете обе работы (например, с помощью переменной BUILD_TAG родительской работы), агрегированные результаты не будут получены. В моем понимании Дженкинс просто смотрит на md5sums, чтобы связать задания ( Агрегирование результатов нисходящего теста и запуск через cli не должны влиять на агрегацию результатов. Каким-то образом происходит что-то дополнительное для поддержания отношения восходящий / нисходящий, о котором я не знаю..,