Chris, Jenkins will re-generate the XML files when ever something is
changed in the Project, like editing the config. There's no real way for
Jenkins to re-create it identically using includes, since once it's loaded
the model into memory it no longer knows what came from an xml include or
not. You're going to have a real tough time taking this approach.

I would suggest looking at some plugins that work on generating the correct
XML from "something" else. Like the Config Slicing plugin to do bulk
changes. CloudBees has a Template plugin to store common configuration in a
template job. There's dozens of plugins to help in this regards.

And to toot my own horn, there's the Job DSL (
https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) plugin which
can create the config.xml for you using a DSL. We use Perforce and have to
deal with viewspecs too, but once we're in Groovy and have programmatic
control it's trivial to build a good view spec based on some variables. We
can generate dozens of jobs which are 99% the same, except for viewspecs,
using a few lines of job dsl code.

-justin

On Mon, Oct 15, 2012 at 1:13 PM, Chris Wozny <[email protected]> wrote:

> All,
>
> I'm currently using Jenkins and the ClearCase plugin to maintain 30+ jobs.
> Many of our projects contain the same configurations and we are looking for
> a way to make one change to a general configuration instead of making that
> change in each project that is relevant as this can become very tedious
> every time we want to change a ClearCase config spec or email address in
> the job. Since most of the configuration is in XML, I attempted to add a
> DOCTYPE ENTITY into a job's config.xml file to "include" another XML file
> in it just to see if it would work. This other XML file contained the
> ClearCase configuration I wanted to use for multiple jobs. When I opened up
> the config.xml file in Microsoft's default XML editor, it understood the
> include and replaced the character entity with the XML in the external
> file. This showed me that my syntax and idea were sound. I then attempted
> to run Jenkins and my console was flooded with hudson.util.IOExceptions
> coming from hudson.XmlFile.read(). I looked at this file and it looks like
> XStream is the XML parser you are using. I'm not sure if XStream supports
> this functionality of including XML files in other XML files, but I wanted
> to see what you, the Jenkins' developers, thought about adding this
> functionality since it allows you to have one XML file define many
> config.xml files or sections within config.xml's. I'm sure I've butchered
> my words somehow, so I've included a link to the XML topic I'm referencing:
>
> http://xml.silmaril.ie/includes.html
>

Reply via email to