CODEWITHSUNDEEP
loopsjenkinsgroovy
Diomedes
Diomedes

Reputation: 21

Can Jenkins and Groovy be used to loop through a list of builds (with params for each) and launch them?

Can Jenkins and Groovy be used to loop through a list of Visual Build Pro builds (with distinct params for each one) and launch the specified build jobs? Each build would require 2 different VBP scripts, one for labeling, the other for building.

There is no need to have these builds run in parallel, having them run sequentially would be fine. Each build job would launch as the input file shown below was processed, with each build job being given the correct Visual Build Pro bld script name, plus all other needed parameters.

A hypothetical input file, containing information on the desired set of builds, would be:

BLD_SCRIPT_NAME PLAT_NAME MARKET NUM_MAJOR NUM_MINOR NUM_MAINT BLD_LABEL BLD_TYPE

Labeling.bld Mercury US 14 2 0 v10000 Dev
ScriptMer.bld Mercury US 14 2 0 v10000 Dev
Labeling.bld Neptune GB 14 2 1 v10001 Rel
ScriptNep.bld Neptune GB 14 2 1 v10001 Rel
Labeling.bld Minerva AU 14 4 0 v10002 Test
ScriptMin.bld Minerva AU 14 4 0 v10002 Test

I have seen pages on the internet that discussed Jenkins/Groovy iterating, but none were applicable to the iterate for build jobs (with params for each) problem I describe above.

I would appreciate any help, please include links / Jenkins examples / Groovy code snippets if you have time.

Upvotes: 1

Views: 6111

Answers (3)

Jeanne Boyarsky
Jeanne Boyarsky

Reputation: 12266

Note: This question was cross posted on CodeRanch. The following is my answer from when I saw it there:

The Groovy plugin can do this. For example:

import hudson.model.*

def csv = "job-1,a\njob-2,b"

csv.eachLine { row ->
    def cols = row.split(',')
    def jobName = cols[0]
    def paramValue = cols[1]

    def params = [new StringParameterValue('paramName', paramValue) ]

    def job = Hudson.instance.getJob(jobName)
    println "Launching ${job.fullName}"
    def future = job.scheduleBuild2(0, new Cause.UpstreamCause(build), new ParametersAction(params))
    future.get()
}

For the jobs where you have actual dependencies, I would recommend having an upstream/downstream dependency to force the order.

Upvotes: 0

Suresh Thayu
Suresh Thayu

Reputation: 2122

In my project, i used groovy to trigger the JobB (parameterized) from the JobA.

JobA has script like for generating builds for Debug and Release.

value=Debug,D1,D2;Release,R1,R2;Prod,P1,P2

String[] env=value.split(';')

for (int i=0;i < env.length;i++){
     String[] data=env[i].split(',')
     build("JobB", Param1:data[0], Param2:data[1], param3:data[2])
}

Upvotes: 2

Tuffwer
Tuffwer

Reputation: 1047

We do this in our build, but I suspect not in the way you're thinking

We have a build manager framework written in groovy (that was written in house, and isn't something I can share) that has a build object which istself a list of configuration objects. We create an object and provide the build info (relevant build file, arguments etc.) for each step in our build and add those objects to the end of a list. Then at the end of this config script we iterate through the list and call a build manager object and pass it each build config object. It parses the object and starts each build (using MSBuild) with the relevant information.

We still have the to do the legwork of defining each item to be built separately in the config file, but it's pretty trivial once the framework is in place. The block to add a configuration looks like this (Names and places have been changed to protect the innocent):

buildObject.addConfiguration(
targets:["project\build\target"],
configs:["Release", "Debug"],
platforms:platform you're building on
filepaths:[],
solutions:["path\to\solution\file"],
buildphases:["1"]
)

We have multiple phases of our build and the buildphases number controls which phase this has been run on.

As far as I know there isn't a built in way of doing this in jenkins unless you want to use the parameterized plugin and define a job for each build and have some sort of top level job trigger all of those jobs. If you want to keep it to one build job you'll have to either find one someone has made, or roll your own groovy framework and define each build.

Upvotes: 0

Related Questions