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 <scotto.alberto...@gmail.com > 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 <kuypers.d...@gmail.com>: > >> 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 <scotto.alberto...@gmail.com>: >> >>> 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 jenkinsci-users+unsubscr...@googlegroups.com. >>> >>> 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 >> jenkinsci-users+unsubscr...@googlegroups.com. >> >> 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
