Indeed, if I generate a new job config.xml file it should be reloas, and yes it takes forever!!! That's mainly why I want to integrate such mechanism directly in a plugin. I didn't look the API yet but I know that we can create job using a REST URL, posting the config.xml.
So I guess it should have a Job constructor which takes a stringify version of a config.xml. It could be a way to achieve my goal. What do you think of this solution? Daniel PETISME +33 (0) 6 69 29 45 55 [email protected] On Sun, Nov 18, 2012 at 3:34 PM, Andrew Melo <[email protected]> wrote: > On Sun, Nov 18, 2012 at 10:26 AM, blalor <[email protected]> wrote: > > I think lots of us are trying to solve this problem. I haven't played > with > > the job-dsl plugin, yet; it sounds like it's on the right path, but as I > > understand it needs to be extended to support specific plugins. > > > > I've got a pretty simple set of Python scripts that I use to build jobs. > > We've got about a dozen projects, each with one or more downstream deploy > > jobs, and another set of parallel regression and automation test jobs. > So > > we're deep into the tens of jobs that need to be maintained. My script > has > > a templatized XML file for each type of job and a config file for each > > project (which could probably be done away with if the projects were > named > > consistently). It uses Jinja to generate the concrete job config.xml > from > > the template and per-project config. It can both generate new jobs and > > update existing jobs with the new config. All I'm missing now is the > > ability to keep people from modifying these templatized jobs! > > The problem with that method (for me at least) is that reloading the > configurations from disk involve rebooting jenkins, which takes > forever and blocks anyone from doing work. Or, do yo have some sort of > way to modify the jobs using the API? > > -Melo > > > > > -- > -- > Andrew Melo >
