Is it OK to link config.xml files?

[Steve K]

Hello,

I have a set of jobs that are identical, except for their names.
For example, I might have a job named "Downstream-Post-Build-Process-Dev" and "Downstream-Post-Build-Process-Release".
The upstream jobs that trigger these jobs tell the downstream job what directory to use for the processing.
I could have the upstream jobs call the same downstream job, for example "Downstream-Post-Build-Process-Generic",
but that is likely to confuse the casual observer of the job's results.

So, to ease maintenance, I would like to link Downstream-Post-Build-Process-Dev\config.xml to Downstream-Post-Build-Process-Release\config.xml.
Are there any known "gotcha's" with respect to linking config.xml files?
FWIW; the Jenkins server is on Windows.

Thanks in advance.

Steve K.

[Nick Stolwijk]

I don't know if that will work.

Normally I use the Template Project Plugin[1] to keep different types of builds in sync.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~

Lord Baden-Powell

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/7d2bf1c5-fbfb-4421-ae2a-8a1302065226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

The most obvious one I can see is that you will need to reload from disk after each and every change to any of the linked jobs... which will be nasty... as otherwise Jenkins will not know that the other jobs have had their configuration changes and thus will not pick up the change and if you go change one of the others you will undo the changes from the first

--

[Ginga, Dick]

FWIW, I do the same thing but use a generic job. To avoid confusion I set the display name to indicate who/what/which job called it. so a history of the generic job could look like:

 

Post-Build-Process-Dev-23

Post-Build-Process-Dev-22

Post-Build-Process-Dev-21

Post-Build-Process-Release-20

Post-Build-Process-Release-19

Post-Build-Process-Dev-18

 

And “actually” what I do is pass in the build number of the caller so the “real” history looks like this:

 

Post-Build-Process-Dev-23

Post-Build-Process-Dev-22

Post-Build-Process-Dev-21

Post-Build-Process-Release-3

Post-Build-Process-Release-2

Post-Build-Process-Dev-20

--

[James Green]

Isn't this what the job-dsl-plugin was designed to "fix"?

On 24 March 2015 at 16:01, Steve K <Steve.K...@carestream.com> wrote:

--

[Steve K]

Thanks for the replies.
There have been four replies and four different approaches.
I will look into using either the Template Project or the Job DSL plugins.
I'm not as concerned about deploying similar jobs, rather I'm more concerned with keeping similar jobs "in synch" as changes need to be made.
Is that a job better suited for the Template Project or the Job DSL plugin?

[Brantone]

A fifth option is https://github.com/JoelJ/ez-templates