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.
