2012-01-16 2 views
10

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

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

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

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

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

ответ

10
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) 

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

+0

Что такое 'currentBuild'? – willkil

+0

Nevermind. Я вижу «build - текущая сборка (см. Hudson.model.AbstractBuild)» на странице [Groovy Postbuild Plugin] (https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin). Я не думаю, что это было, когда я задал вопрос или написал свой ответ. – willkil

+1

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

1

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

+0

Это не то, на что я надеялся, но похоже, что это сработает. Я оставлю это открытым немного в надежде на более простое решение. – willkil

1

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

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

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

+0

Я, наконец, получил шанс попробовать это, 9 месяцев спустя. Ваш код не работает, но он заставил меня начать. Сценарий должен сказать 'manager.hudson' вместо' hudson'. После этого плагин Join сообщает об ошибке «CauseAction», поэтому я использовал 'manager.hudson.queue.schedule (job, 0 causeAction)'. Спасибо, что дал мне искру, в которой я нуждался. – willkil

4

ПРИМЕЧАНИЕ: 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 имеет те же параметры А и В, но также принимает параметр E который по умолчанию «F».Следующий пост сценарий сборки в Job1 копирует свои A и C параметры и установить параметр E конкатенаций A-х и C 'значений s:

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.

1

Это работает для меня с помощью «Execute системы заводной сценарий»

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) 
+0

Работает для меня также. Благодарю. Кроме удаления hudson.model. от каждого вызова метода. – gaoithe

1

Выполнить этот скрипт 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) в вызове функции

Смежные вопросы