我对两者都有丰富的经验。一个简明的回答是Job DSL存在的时间更长,是Netflix的“编码”Jenkins的开源解决方案。它允许您将逻辑和变量引入到Jenkins作业的脚本中,并且通常会使用这些作业为特定项目形成某种“管道”。作为启用作业模板和脚本编写的常用方法,此插件获得了相当多的牵引力。
Jenkins Pipeline(2.0)是一个完全基于DSL的Jenkins工作的新版本,它试图消除将多个作业拼接在一起以填充单个管道的需要,这是迄今为止最常用的Job DSL。最初,由于Pipeline DSL没有提供Job DSL所做的许多功能,并且如上所述Job DSL允许您创建Pipeline作业,它们可以一起用于定义管道。
今天,IMO几乎没有理由使用Job DSL,因为Pipeline是Jenkins支持的Jenkins管道脚本编写机制,它已经达到或超过了Job DSL的大部分功能。正在为Pipeline本地开发新的插件,Jenkins开发人员鼓励那些没有插件与Pipeline集成。而Pipeline有几个优点:
最后,Jenkins Pipeline是目前Jenkins最流行的功能。看看Jenkins World 2016 agenda,你会看到约。 50%的会议涉及管道。没有Job DSL。
我的感觉是理想的方法是同时使用两者。 Pipeline是新的原生Jenkins功能,可以将作业作为代码。但是,如果从头开始构建Jenkins,那么仍然需要创建这些作业。这意味着Jenkins不能100%真正编写脚本并使用代码构建。
你可以做的是使用JOB DSL来构建所有作业的骨架结构,然后使用管道来实现作业。这将允许您100%编写Jenkins脚本,减去要创建的初始种子作业。
也许,最终我们将能够使用管道来完全控制Jenkins(安全性,配置甚至插件)。但在那之前,我认为使用DSL和Pipeline是一种很好的方法。
我的初步答案基于非常有限的经验:
所以回顾一下:Job DSL的DSL用于创建构成管道的作业,Pipeline Plugin的DSL定义了管道本身。
并回答你的问题:管道应该在未来得到更广泛的支持,对我来说看起来更直接(工作是工作,而不是metajob),并且似乎有更多的功能(包括工作流程)。我会使用它,除非你遇到上述showstopper的厄运,并找不到修复/解决方法。
到目前为止,这里没有提到一个重要的区别:测试。使用job-dsl,可以在将DSL代码提交给SCM之前测试DSL代码:https://github.com/sheehan/job-dsl-gradle-example - 这允许本地测试套件在代码运行之前在DSL代码以及Jenkins上运行。据我所知,原生Pipeline方法中没有相应的东西。