Allows you to use any job as a template for other jobs.

Any Jenkins job can be used as a template

• Select Allow this job to be used as a template

A template can be a runnable job in its own right or be disabled and used only as a parent for "real" jobs.

❗ WARNING: Templates have the capacity to magnify a bad decision so should never be used without an automated backup solution in place. ThinBackup plugin is a good candidate for this.

Any Jenkins job can inherit from a template of the same job type.

• Select Use another job as a template and enter the template's name
• Click Apply. When you open the job after this, you will see the configuration copied in from the template.

❗ The same job type (e.g. Maven/Freestyle) is important.

Choose New Item > Copy existing item and enter the template's name. The new job will be automatically created as an implementation.

Synchronisation happens whenever an implementation job or its template is saved. The implementation overwrites its config with that of the template, discarding any local changes.

Only configured items (see Advanced section) are retained.

❗ External edits are not monitored, users must manually Configure>Save after changing the raw config.xml.

One of those is the Parameters section.

• New parameters added to the template are added to the implementation
• Old parameters not in the template are removed from the implementation
  • ❗ Renaming a template parameter counts as a removal and addition - it is not synched as a "rename" and you will lose any customisation.
• Existing parameters are synchronised
  • The parameters' Default Values are retained by the implementation.
  • ❗ You cannot delete choices from a choice parameter, this would require a full remove/add of the property to reset the implementations.

Not everything can be parameterised in a Jenkins job config. Here's a few sample uses

• SCM Repository URL can be a param, allowing completely different projects to be built with the same template
  • Alternatively the param could simply the Git branch (e.g. master, feature)
• Combined with NodeLabel plugin, implementations can specify build node requirements
  • e.g. Only build on Linux or boxes with IPv6
• Parameterized Trigger and Conditional BuildStep plugins are the basis of many flexible configurations based on job parameters