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.
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.
- 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".
- Do 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.
The following video tutorials are currently available:
There are also still some known issues that are currently under examination and will be fixed in future versions:
- Job Config History plugin:
Will lead to a Stack Overflow due to an infinite loop on a property request on startup; this heavily delays the start and slows down Jenkins in general.
- Artifactory plugin:
The artifactory options are not visible on projects/jobs using the inheritance plug-in.
"This build is parameterized" message sometimes appears twice. Only one of the two fields actually contains & controls parameters. The other is a blank stub that does not save anything.
- Rebuilder plugin:
If that plug-in is not installed, you will see a "ClassNotFoundException" on "RebuildValidatorSuppressor". This error is harmless, as all that class does is to disable the Rebuilder plug-in for inheritance-controlled jobs (as the plug-in has its own rebuild implementation). What is not there can't be disabled, you see.
- Various SCM plugins:
Polling will only work for many SCM plug-ins, if the SCM property or its polling property is enabled is defined on a job itself, but not if it's inherited. We are investigating whether this can be fixed without having to alter the code of the SCM plug-ins themselves.
Version 1.4.12 (10. October 2013)
- Hotfix for v1.4.11 -- there was a regression with the "properties not being evaluated in the correct order" bugfix.
Version 184.108.40.206 (09. October 2013)
- Identical to v1.4.11. Re-upload because maven created a snapshot instead of release version
Version 1.4.11 (03. October 2013)
- Fixed issue with properties not being evaluated in the correct order -- some properties were being inherited multiple times, if defined in different parents.
- Layouting fixes and improved support for context-based URLs on many GUI pages
- Replaced many Jelly pages with Groovy scripts
- Changed name of "Child Job Creation" to "Compound Creation".
- Added additional a table to the project overview page to more immediately see direct parents and children that are leafs.
- Moved "project class" from compound-config page to general page. This makes sense, as this field can be used in the "Related Projects View" to sort/filter projects
- Improved rendering of "range" slider element.
- Added option to disallow compound renaming (only relevant for automatically created 'compound' jobs)
- Fixed issue with project-names instead of parameter-names being displayed on "Show Parameter derivation" page
Version 1.4.10 (16. September 2013)
- Added new permission type "Configure Versions". This allows you to split general "Configure" rights and the right to set a version to stable. The "Administer" permission implies the right to configure versions.
- Fixed issue with SubTasks not being inherited. Now, all properties that contributed additional tasks to be processed on other Executors should work correctly.
- Fixed Stack Overflow due to Parameter References. This could occur if you defined the same parameter twice.
Version 1.4.9 (22. August 2013)
- Fixed issue with relative path in Jelly file for "Inheritable Parameter" that caused issue if Jenkins server was a Windows host. (Found and fixed by Steven Craft)
- Removed superfluous scanning of all projects when resolving project references (improves speed on large installations)
- Fixed issue with broken links on th "Show References" page if Jenkins ran in a context other than "/"
- Fixed several possible Null-Pointer-Exceptions in various parts of the plug-in.
- Added several test-cases to prevent future regressions. Do note that these tests are disabled on Windows, due to a bug in Jenkins < 1.520
- Fixed issue with the "magic node-label" (which, if set on a node, makes sure that only tests that use that label are scheduled on this machine) being applied wrong if a job had no label set at all.
Version 1.4.8 (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.