> I'm not sure why you would want yet another way to do it. Basically for migration and maintenance purposes
1) I've got a set of scripts that can populate my Hudson jobs. So I can delete all the jobs, re-run my scripts and nearly everything is back to where it was. I took those scripts, re-did the underlying xml manipulation classes to work against a Jenkins server, and now I can re-constitute my jobs onto Jenkins. 2) As a nice side-effect, I wrote the scripts to warn me when the expected configuration is different from the actual configuration. I can find out if something got changed "by accident" and if I want I can either revert it on the Server or update my scripts to make it permanent 3) Started off with 15 jobs and because I scripted the heck out of the thing, I was able to create lot's of little jobs at will (I currently have 750 jobs). So: adding a job or jobs is trivial, doing bulk changes is trivial, etc. The scripts opened up a lot of possibilities for doing things in Hudson/Jenkins that would have been overwhelming to do manually. The effort to write the scripts was initially high , but over time, the maintenance effort has become puny compared to what it would have been. 4) the scripts are in source control. So I can revert to a previous Jenkins configuration, by: - reverting the scripts to a previous revision - re-running them This process only takes around 10-15 minutes compared to ?? minutes to do it manually. John -- 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/groups/opt_out.
