We have 420+ jobs. They are currently in Hudson but I am trying to convert to Jenkins, see below.
To manage them I wrote a nice set of ruby scripts where I declared the jobs and load them into a database (i.e. a ruby hash). Then I use that DB to check if a job is new and needs to be created, or if it's old and needs to be deleted. The job creation is automated, but I do the job deletion manually - just in case. It also compares the job settings against the DB contents and if they don't match, it will show me the differences and then, if I have the save_flag set to true, it will also update the Hudson job to match. This is a great feature. If someone manually changes the job, I know about it and I can revert their changes or change my scripts to match their updates. I used ruby since I could easily create base classes, derived classes etc to accommodate the fact that most of the jobs are nearly identical. There are only a few base classes and all the other ones derive from them. Going back to your post, you can use the same technique. In your case you'd have say 10, or most likely fewer, base classes and 2 derived classes, one each for the trunk/branch jobs. The jobs would be created from the derived classes and then be stored in the DB (again just a simple hash). Once the DB is setup, a simple loop through it would configure all your jobs in one fell swoop. For example, mine sets up email addresses, sets job priorities, appointed slave nodes, job triggers, SCM triggers, Timer triggers, Locks, Xvnc, SCM repositories and a few others. I put these scripts into our source control and now I have an audit trail of all the changes made to the jobs configurations. If something bad really happens, I could even revert to a prior version of the job configurations (it may require some changes of course). And finally, the scripts provide an abstraction layer away from Hudson. I could convert to Jenkins by changing the job creation/update/delete portion of the scripts and voila, I have the exact same jobs on a Jenkins server. But all is not peaches and cream. As I said above I'm using Hudson. I used the ruby gem hudson-remote-api to shield me from some of the low level details. Unfortunately that gem does not: 1) handle plug-ins 2) handle Jenkins The first means I had to "manually" change the XML nodes for each plugin. There is some basic structural similarities in the XML across all plugins but there are enough exceptions that it is a headache. The second means I would have to re-engineer the same hacks against the Jenkins XML nodes. There is a gem jenkins-remote-api but it is much less developed than hudson-remote-api. The "solution" to both is to have all Hudson and Jenkins plug-in developers provide a uniform scripting front-end to their configuration XML. A highly unlikely scenario but you never know... Not sure how much that helps you, but perhaps it can give you some potential avenues to try. John On Tue, Nov 20, 2012 at 2:27 PM, Sami Tikka <sjti...@gmail.com> wrote: > I type some Groovy commands into the Script Console you can find under the > Manage Jenkins link in the sidebar. > > -- Sami > > Marcin Biegan <marcin.bie...@gmail.com> kirjoitti 15.11.2012 kello 2.39: > > > Hi, > > > > I wanted to ask how do you handle configuring multiple jobs. We have > > about 10 maven projects to build in at least 2 versions (trunk/ > > branch), which makes 20 jobs, some more for additional tests, > > releases, maybe deployment, verification, etc. Manually adding > > permissions and adjusting configuration of jobs is cumbersome. Is > > there a working plugin which would allow to set some 'parent' job > > which would define default configuration? (Template Project Plugin is > > not enough, because it 'works' only at job creation). I know also > > about Configuration Slicing Plugin, but this will not work in my case > > as it requires admin permissions. > > > > Thanks > > Marcin Biegan > >
