Extension Points defined in Project Inheritance Plugin

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.causes.BuildCauseOverride]

This class serves as an extension point to enable plugins to contribute additional entries for jenkinsdoc:Cause] .

Implementations:

(no known implementations)

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.util.BuildDiscardPreventer]

This class servers as an extension point which, when extended, allow a plugin to prevent the deletion of a build.

Do note: Explicit calls to jenkinsdoc:Run=delete()] will still remove the build, but deletions triggered by a jenkinsdoc:BuildDiscarder] or via the GUI will be prevented.</p>

Implementations:

(no known implementations)

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.view.BuildFlowScriptExtension]

This class is an extension point to add new handlers for turning certain jenkinsdoc:Builder] into executable shell scripts

Implementations:

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.view.BuildViewExtension]

This class servers as an extension point to render additional configuration entries for a build action.

It is useful to add additional properties to the build; regardless of whether or not this happens on a build or re-build.

The extension needs to implement a "value.groovy" or "value.jelly" which gets added into the form tag of the build submission. The name of this file can be overridden via jenkinsdoc:=getValuePage()] .

The fields will be put into the JSON form data inside the jenkinsdoc:StaplerRequest] when the build is executed. For simplicity's sake, the method jenkinsdoc:=onBuild(AbstractProject, StaplerRequest)] will be called whenever a build is configured.</p>

Implementations:

(no known implementations)

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.inheritance.InheritanceSelector]

Extension point that allows other plugins to decide how a particular type of object should be treated during inheritance.

During inheritance, the settings of multiple projects need to be merged into one object, since the leaf project needs to respond to Jenkins as if it did not do any inheritance.

For example, a project might inherit multiple jenkinsdoc:SCM] objects, but it has to be ensured that only one is returned to Jenkins. The default behaviour in that case is to use jenkinsdoc:SCM] that was defined "last". If you want to override that behaviour, just register a new subclass of jenkinsdoc:InheritanceSelector] that has jenkinsdoc:SCM] as the template type and returns a mode other than jenkinsdoc:MODE=NOT_RESPONSIBLE] fpr jenkinsdoc:SCM] in jenkinsdoc:=getModeFor(Class)] .

</p>

Implementations:

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.rebuild.RebuildParameterFilter]

This extension point allows you, to specify whether a given parameter should be included in a rebuild of a job, or not.

It can be used to remove automatically generated parameters, so that the rebuild can progress safely.

Each jenkinsdoc:RebuildParameterFilter] is called for each parameter of the previous build, that is about to be rebuilt. If any filter returns false when queried for jenkinsdoc:=isParameterAllowed(ParameterValue)] , the value is not copied into the new build.

Do note, that the parameter may still be present -- only that in these cases the default value from the project will be used, as if there were no value from the previous build.

Also do note, that the current rebuild implementation filters out all parameters, that are not jenkinsdoc:StringParameterValue] s (or subclasses). This is not guaranteed though, which is why this class accepts generic jenkinsdoc:ParameterValue] s.</p>

Implementations:

(no known implementations)

jenkinsdoc:project-inheritance:hudson.plugins.project_inheritance.projects.versioning.VersionChangeListener]

This class tracks whenever a change is done on show version related item.

Implementations:

(no known implementations)