sorry for the delay, I've been traveling. It isn't just the initial installation or recovery from backups, it's also the ongoing maintenance. Moving all the configs into an SCM would work; rsyncing works too. But these techniques don't get you a "higher level" view of the jobs.
For example I have two dev branches int and trunk and therefore two sets of jobs, one for the int and one for the trunk branches. The two sets of jobs are nearly identical and so when I make a change to one, I always always *must* make a change to the other. My scripts capture that relationship between the two sets of jobs, using rsync (for example) does not. I also have a traceability requirement, in other words whenever a change is made it has to be captured in some sort of history. Moving the configs into an SCM would provide that (rsync wouldn't). But putting my scripts into an SCM also provides it and the "higher level" view of the jobs too. Finally, it's becoming clear I also need to provide a snapshot report of the Jenkins configuration whenever I do an "official" release of our software. In other words I release the binaries but also enough information that I can recreate the build environment so those particular binaries can be recreated at some point in the future if necessary. It's easy enough to get compiler versions and the like, but getting the relevant Jenkins config is a little trickier. Just dumping the config xml files would satisfy this requirement but would also include irrelevant stuff that I'd prefer not to put in the snapshot. In short, I already have the scripts for the jobs and I have almost everything I need via those scripts. I'd like to finish them off and get the core/common config information via those scripts as well. So, is the API access in the future? On Thu, Aug 8, 2013 at 3:16 PM, Daniel Beck <m...@beckweb.net> wrote: > What are you actually trying to accomplish? I mean, if you're starting > with a fresh instance (or at least set most of the settings) anyway, what's > wrong with checking it out from SCM, rsyncing, or cloning a template VM? > > On 08.08.2013, at 22:51, J Arrizza <cppge...@gmail.com> wrote: > > > I currently have a set of scripts that I use to get/set all of the job > parameters/settings/configuration. This means that I can take a machine > with vanilla jenkins on it and pretty much recreate everything I care about > in all the jobs. > > > > But there seems to be a few things missing to make this 100% automated: > > - getting a list of plugins and their versions; being able to install > plugins from the API > > - setting up views > > - setting Global Properies (e,g Environment Variables) > > - setting Locks (for the locks and latches plugin) on the "Manage > Jenkins" page > > - setting Xnvc (for the xvnc plugin) on the "Manage Jenkins" page > > - setting Jenkins Location information and admin email info > > - setting email notification information > > - setting up Nodes > > > > I can take the "low road" and use scp to get the config.xml, modify it > and push it back, but before I do that, is there any chance this kind of > access is in future plans for Jenkins? > > > > Thanks > > 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. > > > > > > -- > 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. > > > -- 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.
