传统的 Jenkins Job
在相当深的类型层次结构中定义:
FreestyleProject
→ Project
→ AbstractProject
→ Job
→ AbstractItem
→ Item
。
(以及配对的 Run
类型: FreestyleBuild
等)
在旧版本的Jenkins中,很多有趣的实现都在 AbstractProject
(或 AbstractBuild
)中,
其中包含了许多不存在于 Job
(或 Run
)中的特性。
流水线也需要这些特性中的一些,例如使用编程方式启动构建(可选地使用参数),
或延迟加载构建记录,或与 SCM 触发器集成。
其他特性不适用于流水线,比如每个构建声明单个 SCM 和单个工作空间,
或者绑定到特定的标签,或者在单个 Java 方法调用的范围内运行线性构建步骤序列,
或者有一个简单的构建步骤和包装的列表,其配置保证从构建到构建保持不变。
WorkflowJob
直接扩展 Job
,因为它不能像一个 AbstractProject
。
因此需要进行一些重构,以使其它 Job
类型的相关特性可用,无需代码或 API 复制。
而不是在类型层次中引入另一个层次(并且始终冻结哪一个功能比其他更“通用”的决定),mixin 被引入。
一组相关功能的每个封装最初绑定到 AbstractProject
,但现在也可用
WorkflowJob
(以及其他可能的 Job
类型)。
-
ParameterizedJobMixIn
允许将作业调度到队列中(旧的 BuildableItem
不足),
还要注意构建参数和REST构建触发器。
-
SCMTriggerItem
集成了 SCMTrigger
,包括工作正在使用的 SCM 的定义,
以及它应该如何执行轮询。 它还允许各种插件与多个 SCM 插件互操作
而不需要明确的依赖关系。 取代并弃用 SCMedItem
。
-
LazyBuildMixIn
处理延迟加载构建记录(在Jenkins 1.485
中引入的系统)的流水线。
对于流水线兼容性,以前通常指的是 AbstractProject
/AbstractBuild
的插件
需要开始处理 Job
/Run
,但也可能需要引用 ParameterizedJobMixIn
和/或 SCMTriggerItem
。
(外部代码很少需要 LazyBuildMixIn
,因为 Job
/Run
中定义的方法足以满足典型的需求。)
流水线的未来改进可能需要从 AbstractProject
/AbstractBuild
中提取更多的实现代码。
主要限制是需要重新调整二进制兼容性。