> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
