Please give this a high priority!

This is a feature that would decrease our configuration
and maintenance effort by factor 3!

We have several Jobs which are used as template for other Jobs
which have only minor changes in configuration parameters.

All the rest of the configuration is identical and shared from the main Job:

• scm repositories (which currently does not work for some Jobs because of https://issues.jenkins-ci.org/browse/JENKINS-24404)
• build steps
• post-build actions
• ...

This is one of the last missing _shared configuration item_s for us

Would this be an automated import because it's too much hassle to manually add parameters to the Calling job that the Template job uses??

Actually ... is this intended for
(a.) the template project to import params itself? --> I would think that'd become a confusing subset.
(b.) the template project to use the params from the calling project? --> I believe it already does that.
(c.) ???

Hi brantone,

Thank you very much for looking into this!
We need this functionality more and more.

I would use this as follows:

1. We have a Template Job name "Template_Job"
   • This Job defines parameter "PARAMETER1", "PARAMETER2" and "PARAMETER3"
2. We have several Jobs, name MyJob1, MyJob2, MyJob3, ...
   • All of these Jobs use "Template_Job"
   • These Jobs import one or more of the parameters from the template job.

I suggest the most flexible way to use the parameters from the "Template_Job" (in e.g. "MyJob1") is:

1. Select "This build is parameterised"
2. "Add Parameter" -> "Use parameter from another Job" (this would be the new part)
3. "Select" parameter name
   • When performing a manual build, I suggest it should be possible to obtain all required parameter info from the "Template_Job" configuration.
     (We should see the same parameter info as when the parameters would be configured in "MyJob1" directly)

Note: One difficult part may be recursion:
Suppose we have:

1. Template Job "Template_Job1" and "Template_Job2"
   • These are simple template jobs
   • "Template_Job1" defines parameter "PARAMETER1_1", "PARAMETER1_2" and "PARAMETER1_3"
   • "Template_Job2" defines parameter "PARAMETER2_1", "PARAMETER2_2" and "PARAMETER2_3"
2. Template Job "Template_JobX"
   • This Job uses parameters, build steps, post build steps, etc. from "Template_Job1" and "Template_Job2"
   • E.g. Using parameters "PARAMETER1_1" and "PARAMETER1_2" from "Template_Job1"
   • E.g. Using parameters "PARAMETER2_2" and "PARAMETER2_3" from "Template_Job2"
3. Actual main Job "MyJob1"
   • Using parameters from "Template_JobX"
   • E.g. Using parameters "PARAMETER1_1" and "PARAMETER1_2" from "Template_JobX" (which actually came from "Template_Job1")
   • E.g. Using parameters "PARAMETER2_2" from "Template_JobX" (which actually came from from "Template_Job2")
   • E.g. Additionally using parameter "PARAMETER1_3" from "Template_Job1"

If this is too complex too implement, it can be simplified:

1. Template Job configuration same as shown above.
2. Actual main Job "MyJob1"
   • E.g. (Directly) using parameters "PARAMETER1_1", "PARAMETER1_2" and "PARAMETER1_3" from "Template_Job1"
   • E.g. (Directly) using parameters "PARAMETER2_2" and "PARAMETER2_3" from "Template_Job2"

I hope this helps you figuring out the design.

with best regards,
Tom.

Something like "Use parameter from another Job" would be nice.

Would it bring in just parameter names or values as well?
Since the Template project is acting like a library, what's the purpose in using parameters if they're always "hard coded" anyway?

Hi brantone,

Totally agree on the title name.

I suppose the values should be taken optionally (if possible):

1. Some parameters can be shared
   • e.g. supported choices for the template build steps.
2. Some parameters have no default in the template, but should have a default value in the Job using the template.
   • e.g. A string parameter defining some subdirectory to be processed by the template Job build steps.
3. Some parameters have partial common value for the template job
   • E.g. List subversion tags and more. Usually using the same repository, but may default to different branch
4. ...

There seems to be no plausible solution for either or not bringing in the value.

So, I suggest to make it flexible and make either or not using the value from the template optional. The case where partial common values are used could be solved as follows. The configuration of the job using the template:

• When choosing to override the parameter value, the Template Plugin should default the value to a copy of the parameter value as defined in the template job.
• It can then change the (part of) the parameter value where required.

Code contributions definitely welcome ... beyond the "Use parameters from other Job", this sounds like a hefty change with a few possible use cases. Issues of quasi-"parameter inheritance" would come into question (ex: if both jobs have same value, which takes precedence), as well as the whole "pick 'n choose" nature.
This might getting a bit beyond the simple elegant intention of the plugin: essentially "drop in place" piece to a job.
If there's a need for more parameter control and enforcement, could look at using https://github.com/JoelJ/ez-templates ... it's a great plugin, which I use in conjunction with TemplateProject to define the overall simple skeletal "template" which then calls pieces for builders + publishers using Template-Project plugin.

Hi brantone,

Yes, I know, it's in my nature to keep all my code very flexible (and sometimes too complex )
I'll take a look at the ez-templates too...

I think that the Template Plugin should have (at least some basic) parameter support since the build steps
and post-build-steps can use parameters and they should be defined and shared somewhere.
The Template Job can then actually serve as a self-contained template.

Please correct me if I'm wrong in my opinion!

Second proposal

A (possible) easy (and yet pretty flexible) way would be to

• Add template parameter "Use parameter from other Job"
  • Select Job name
  • Select parameter name

The Template Plugin could then:

• Take name and value of the parameter.

Use case

Well, just as described above.

When another Job wants to have other parameter value(s), it just doesn't include the parameter from the template Job, but:

• When the other Job needs default value (e.g. String Parameter) : Add a String Parameter with the same name, but other default value.
• When the allowed values (e.g. Choice Parameter) needs to be overridden: Add a Choice Parameter with other choices
• ...

Issues

When including parameters with the same name from different _Template Job_s:

• The injected parameters would have the same name.
• IMHO, this is not a real issue since the user may expect other issues when using build-step from two different template jobs, using the same parameter name. God knows what the parameter value is used for in the build steps!

When the template Job changes a parameter name which is overridden in another Job:

• Then the other Job will not be updated, nor notified about the change...
  Any others I overlooked?