It does look similar. However, the parameters it handles ( e.g blockBuildWhenDownstreamBuilding) are part of the default Jenkins behavior. At some point, they will also have to add external plugin support. This is where the bigger problem is waiting for them. If they can find a very simple, very elegant way to handle a diversity of Jenkins plugins.
One way is they could use a plugin for each Jenkins plugin. And if they want to support Hudson and thereby the conversion to Jenkins, they would have to provide two plugins, one each for Hudson and Jenkins. The YAML database is a nice touch. It might work well for them, if they keep it minimal and simple. In their doc they imply it should be checked in to source control. the idea being that all aspects of the jobs are held in YAML. I suspect that approach will eventually cause problems for them. My preference is to build the db every time I run the scripts. This allows a bunch of fairly complex behavior to be captured by the scripting code. For example, it is possible to enforce a job naming convention by writing a bit of code to generate the names. To change the naming convention, I change that bit of code. If the names are already in YAML, then I'd have to "hack" the names manually with a text editor. In any case, it might work quite well for the OP. It all depends on his exact set up. John On Wed, Nov 21, 2012 at 10:03 AM, William Soula < william.so...@drillinginfo.com> wrote: > What you describe sounds very similar to the jenkins-job-builder project > from openstack: > https://github.com/openstack-ci/jenkins-job-builder > > Will >
