I've done templated builds using the technique described in this article and it worked quite well: http://www.blackpepper.co.uk/generating-new-jenkins-jobs-from-templates-and-parameterised-builds/
For the matrix builds... take a look at the combination filter. This plug-in might also be useful though I've never used it myself: https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Combinations+Plugin To make my life easier I had another job triggering my matrix job (using parameterized trigger) so I could have a bunch of preset combinations that I could use. I think I had single runs, a slightly larger set for debugging, and a huge set for production releases. It was at a previous job so I don't have the examples handy. I just passed the combination filter value in as a parameter value. Cheers, Ben On Sat, Jun 14, 2014 at 7:15 PM, Alberto Scotto <[email protected] > wrote: > Turns out there is a builtin solution that does what I want. > > https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project > > And it is mentioned in "Jenknis the definitive guide" specifically as the > way to go when building jobs running web tests against multiple > browsers/OSs. > > Still, one lack I can see: you can't build a single combination, as the > build btn is present only at the "top level". > > Also, I don't like the fact that it is implemented as a different type of > project (you need to specifically create a "multi-configuration project"), > and I'm afraid that you lose something compared to "build a mvn project", > but I don't know for sure. > Anyway, I think it would be a much cleaner solution if it were an option > *pluggable* in every type of project. > > We may work that out. Anyone? > > > > Alberto Scotto > alb-i986.me > [image: Alberto Scotto on about.me] > <http://alb-i986.me> > > > 2014-06-13 9:33 GMT+01:00 Dirk Kuypers <[email protected]>: > >> Hi, >> >> I use the job-dsl plugin to generate thousands of test projects via a >> groovy script. I have a template job and some string arrays with my >> parameters for test categories which are iterated for job generation. >> >> Some of the main code snippets: >> >> def create_windowsBatch = { name, filter -> >> return """cd %CCRoot% >> MKDIR ..\\TestResults >> UnitTest.bat ConformanceTests /resultsfile:..\\TestResults\\${name}.trx >> /category:\"$filter\" """ >> } >> >> def create_project = { my_name, filter, my_priority, day -> >> >> def str_myName = my_name >> println("Creating/Reconfiguring project with parameters: $my_name, >> $filter, $my_priority, $day") >> >> def str_batchfile = create_windowsBatch(my_name, filter) >> def str_jobDescription = create_jobDescription(filter) >> >> job { >> disabled(false) >> name(str_myName) >> description(str_jobDescription) >> using 'Nightly_Tests_Template' >> logRotator(-1, 10, -1, 5) >> priority (my_priority) >> environmentVariables( CCRoot:"\${WORKSPACE}\\${str_upstream_job}" ) >> parameters { >> stringParam("UPSTREAM_JOB", "${str_upstream_job}", "The upstream job name >> to use for this build") >> } >> triggers { >> cron("30 20 * * ${day}") >> } >> scm { >> cloneWorkspace(str_upstream_job, "Not Failed") >> } >> steps { >> batchFile(str_batchfile) >> } >> } >> counter++ >> } >> >> [...] >> >> for (item_systemType in str_allSystemTypes) >> { >> for (item_applicationType in str_applicationTypesToSplit) >> { >> >> create_project("${jobname_factory("$item_applicationType-$item_systemType", >> "WCDMA")}", "$item_applicationType&$item_systemType&Virtual", 120, >> "$str_day") >> } >> } >> >> HTH >> Dirk >> >> >> >> 2014-06-13 3:14 GMT+02:00 Alberto Scotto <[email protected]>: >> >>> Hi >>> >>> Long story short, I was wondering if anyone ever felt the need for (and >>> knows of any implementation of) the possibility of "instantiating" (OO >>> terminology) a parametrized build. >>> What I mean is treating a parametrized build as a template, from which >>> many "instances" can be generated. >>> Each instance is supposed to define a different combination of values >>> for the parameters. >>> The final goal is twofold: >>> 1. DRY (which is given simply by the parametrized build concept) >>> 2.1 having separate build histories / test reports for each instance >>> (otherwise it would be a mess) >>> 2.2 the instances would be schedulable directly in jenkins UI (while a >>> parametrized build is not) >>> >>> The template would then be used only for: >>> - manual builds >>> - changing the config for all of the instances at once >>> >>> >>> Now, time for some context, as I may be missing something in my overall >>> approach. >>> You are welcome to point me in the right direction :) >>> >>> >>> I have a maven project with a suite of selenium tests that I want >>> jenkins to run. >>> The suite is parametrized: browser, OS, test environment. >>> So, I can run it e.g. with `mvn test -Dbrowser=chrome -Dplatform=win >>> [..]`. >>> >>> I want a separate test report for each combination of my parameters. >>> As a newbie, my first solution was "Copy existing job". >>> Quick and dirty. But effective. >>> As you will know, problems arise when you need to make a change to the >>> configuration of the job, and you want to keep in sync all of these >>> copy&pasted jobs. >>> Then I found the parametrized build feature. >>> It's very cool (code reuse/maintainability++), but the test report and >>> the build history is shared among all of the actual builds, therefore I can >>> not rely on them for a tidy reporting like "this test is always failing on >>> IE; but it isn't on chrome", and so on. >>> >>> >>> Thank you very much in advance >>> >>> AS >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Jenkins Users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jenkinsci-users/N7x8EL8hBL4/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
