Jobs are defined in a fairly deep type hierarchy:
(As well as paired
In older versions of Jenkins, much of the interesting implementation was in
which was packed full of assorted features not present in
Some of these features were also needed by Pipeline, like having a programmatic way to start a build (optionally with parameters),
or lazy-load build records, or integrate with SCM triggers.
Others were not applicable to Pipeline, like declaring a single SCM and a single workspace per build,
or being tied to a specific label, or running a linear sequence of build steps within the scope of a single Java method call,
or having a simple list of build steps and wrappers whose configuration is guaranteed to remain the same from build to build.
WorkflowJob directly extends
Job since it cannot act like an
Therefore some refactoring was needed, to make the relevant features available to other
Job types without code or API duplication.
Rather than introduce yet another level into the type hierarchy (and freezing for all time the decision about which
features are more “generic” than others), mixins were introduced.
Each encapsulates a set of related functionality originally tied to
AbstractProject but now also usable from
WorkflowJob (and potentially other future
ParameterizedJobMixIn allows a job to be scheduled to the queue (the older
BuildableItem was inadequate),
taking care also of build parameters and the REST build trigger.
SCMTriggerItem integrates with
SCMTrigger, including a definition of which SCM or SCMs a job is using,
and how it should perform polling. It also allows various plugins to interoperate with the Multiple SCMs plugin
without needing an explicit dependency. Supersedes and deprecates
LazyBuildMixIn handles the plumbing of lazy-loading build records (a system introduced in Jenkins
For Pipeline compatibility, plugins formerly referring to
AbstractBuild will generally
need to start dealing with
Run but may also need to refer to
LazyBuildMixIn is rarely needed from outside code, as the methods defined in
Run suffice for typical purposes.)
Future improvements to Pipeline may well require yet more implementation code to be extracted from
The main constraint is the need to retain binary compatibility.