Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Plugin Information

No information for the plugin 'inheritance-plugin' is available. It may have been removed from distribution.

The purpose of this plugin is to bring true inheritance of properties between multiple job definitions to Jenkins. This allows you to define common properties only once and inherit them to multiple projects.

Description 

The role of this plug-in can be broadly described as bringing the concept of property inheritance to Jenkins. The goal is to fulfil the following statements:

  • Instead of having to define the same property multiple times across as many projects; it should be possible for many projects to refer to the same property that is defined only once.
    or rephrased:
  • Everything that is defined multiple times but used in the same way, should be defined only once and simply referred to many times.

In a way, you can think of this plugin this way: If Jenkins is the C language, this plugin is its C++ equivalent.

Ideal candidates for this are, for example, the SCM setup, common pre-build and post-build steps as well as cleanup and logging properties.

Additionally, the plugin offers the following nice feature additions:

  • A simple versioning system, allowing you to easily go back to a past version of any job configuration and test new features without affecting the runtime.
  • The ability to use a custom workspace location (that can optionally make use of parameter values) that uses Jenkins' workspace locking mechanism so that the Job can still be executed multiple times on the same host without collision.
    • This is highly useful if many projects make use of the same remote repository. Just use the repository name as workspace location to cut down on the number of workspaces.
  • The ability to automatically generate child jobs by joining multiple parent jobs together according to a parameterized "recipe".
    • Done note that this ability is currently too inflexible for broad use. It will be made much easier to use in future versions, though.
  • Possibility to define a special "magic" label that makes sure that only those jobs that depend on this label get executed on a host.
    Think of it this way:
    • Normal Jenkins labels are useful to make sure that a particular set of jobs can run on a particular set of machines.
    • The "magic" node label makes sure that only a particular set of jobs can run on a  particular set of machines -- and no others.
    • More precisely, it makes sure that those jobs that do not reference the label will not be executed on those hosts that have this label.

Video tutorials 

The following video tutorials are currently available:

Changelog

Version 1.4.7 (01 July 2013)

  • Initial public release
  • Fixed deadlock occurring in certain situations involving build Queue queries
  • Added option to hide "rarely changed" build parameters from the build screen.
  • No labels