Как я могу динамически запускать последующие сборки в jenkins?

Мы хотим динамически запускать интеграционные тесты в разных последующих строках в jenkins. У нас есть проект с параметризованным интеграционным тестом, который принимает тестовое имя в качестве параметра. Мы динамически определяем наши тестовые имена из репозитория git.

У нас есть родительский проект, который использует jenkins-cli для запуска сборки проекта интеграции для каждого теста, найденного в исходном коде. Проект родительского проекта и интеграции связан с помощью сопоставления отпечатков пальцев.

Проблема с этим подходом заключается в том, что результаты совокупных тестов не работают. Я думаю, проблема в том, что тесты интеграции "вниз по течению" запускаются через jenkins-cli, поэтому дженкинс не понимает, что они находятся ниже по течению.

Я просмотрел много плагинов jenkins, чтобы попытаться заставить это работать. Плагины Join и Parameterized Trigger не помогают, потому что они ожидают создания статического списка проектов. Задания параметров, доступные для параметризованного триггера, не будут работать либо потому, что нет factory для создания произвольного списка параметров. Плагин Log Trigger не работает.

Плагин Postwild Groovy выглядит так, как будто он должен работать, но я не мог понять, как вызвать из него сборку.

Ответ 1

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)

Вот что, наконец, сработало для меня.

Ответ 2

ПРИМЕЧАНИЕ. Pipeline Plugin должен сделать этот вопрос спорным, но у меня не было возможности обновить нашу инфраструктуру.

Чтобы запустить параметры ниже без:

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". Следующая публикация post script в 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.

Ответ 3

Поскольку вы уже начинаете работу по нисходящему потоку динамически, как насчет того, как вы дожидаетесь, пока не закончите, и не скопируйте файлы результатов теста (я бы их архивировал в нисходящих заданиях, а затем просто загружал артефакты сборки) в родительское рабочее пространство. Возможно, вам придется агрегировать файлы вручную, в зависимости от того, может ли тестовый плагин работать с несколькими страницами результатов теста. На этапе post post родительских заданий настройте соответствующий тестовый плагин.

Ответ 4

Используя плагин Groovy Postbuild, возможно, что-то вроде этого будет работать (не пробовал)

def job = hudson.getItem(jobname)
hudson.queue.schedule(job)

Я действительно удивлен, что если вы отпечатаете оба задания (например, с переменной BUILD_TAG родительского задания), агрегированные результаты не будут получены. В моем понимании Дженкинс просто смотрит на md5sums для сопоставления заданий (Агрегатировать результаты тестирования ниже по течению и запуск через cli не должен влиять на агрегирование результатов. что-то дополнительное для поддержания отношения вверх/вниз по течению, о котором я не знаю...

Ответ 5

Это сработало для меня, используя "Execute system groovy script "

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)

Ответ 6

Выполните этот Groovy script

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) в вызове функции