I called the command line to extract the job definition, then stored that definition in source control. I could replay it at any time.
That did not update job definitions when they changed. It did not detect changes (other than through the version control system diff mechanism). It was not attempting to code Jenkins job definitions in a DRY fashion. It was simple to maintain and helped me reconstruct environments more readily on those rare times when I needed to reconstruct them. Mark Waite On Fri, Feb 21, 2014 at 8:14 AM, phil swenson <phil.swen...@gmail.com>wrote: > Hi, we have a large number of jenkins jobs and would like to automate and > version control their configuration. > > From what I can tell, most people just manually config their jobs via the > UI. Unless there are only a few very simple jobs, this leads to an > unmanageable mess. > > I think the jobs should be coded in a DRY fashion, version controlled, and > deployed via a scripted system. > > Here are the approaches I am aware of: > > 1) scripting via command line (jenkins cli) > 2) scripting via the rest web services > 3) chef cookbook http://community.opscode.com/cookbooks/jenkins > > What are most people doing? > Any recommendations? > > thanks > phil > > -- > 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. > -- Thanks! Mark Waite -- 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.
