Hi there, try the Configuration Slicing plugin. It is good to have some jobs at hand so that you can see how the interface is designed. I don't feel this obviously designed or user friendly at first glance. But if the interface already has some jobs loaded and shows you what you can change in groups is it just a matter of minutes to understand it. It can be adapted to own needs with Groovy if I recall right although this is not mentioned on https://wiki.jenkins-ci.org/display/JENKINS/Configuration+Slicing+Plugin
Anyways, quite convenient and could become very powerful in your daily work Take care Jan On 20 Mrz., 18:59, Andrew Melo <andrew.m...@gmail.com> wrote: > On Tue, Mar 20, 2012 at 12:54 PM, Tony P <tony...@cantabrian.co.nz> wrote: > > Hi, > > > I have to say "Template" is not quite the right word but I can't > > currently think of a better one.. > > > We have quite a few builds that are based on the same "template", they > > are all clones of a particular build I have called > > "Generic_Ivy_Module_Template". All these jobs are identical to the > > generic one aside from a handful of changes, such as the location of > > the source code and project name. > > > All good so far. > > > If I decide to make a change to the master "Template" and make this > > change effective for all its clones then I need to go into each and > > every clone and update them. Yes I know I can change the config.xml > > using a global search and replace - actually that is often what I do. > > > However it would be really cool to have a better mechanism, ideally > > where there was some sort of master job and any changes to that we > > automatically used by the clones. Something like this may exist and I > > have missed it. > > > Incidentally I have multiple "templates". > > Actually I was wondering the same thing. In my case, I would like to use > the exact same build, but have triggered-by-SCM results and > triggered-manually results (like a try server) separated. That way the > build would be the same in both cases, but the historical test results > wouldn't be mixed up like they are currently. Having two separate bulds > makes it really easy to desynchronize the two. > > > > > Thanks > > -- > -- > Andrew Melo
