Job插件与管道插件

Question

作业DSL插件和管道插件的主要区别是什么？

1. 两者都为创造有计划的就业机会提供了途径。
2. 哪一种是最好的前进方式，为什么呢？
3. 如果两者的功能相似，它们是否有不同的用例？
4. 由于Jenkins2.0将把管道作为代码来关注，这是否意味着作业- DSL没有未来，或者管道插件是Job插件的下一个步骤？

Answer 1

我在这两方面都有丰富的经验。简洁的回答是，Job已经存在了很长时间，是Netflix“编码”Jenkins的开源解决方案。它允许您在为Jenkins作业编写脚本时引入逻辑和变量，通常情况下，您可以使用这些作业为特定项目形成某种“管道”。这个插件作为启用作业模板和脚本的一种常见方式，得到了相当多的支持。

Jenkins管道(2.0)是Jenkins作业的新化身，它完全基于DSL，并试图消除将多个作业缝合在一起来填充单个管道的需要，这是jobs目前最常用的方法。最初，由于管道DSL没有提供jobs所做的许多功能，而且如上所述，jobs将允许您创建管道作业，因此可以一起使用它们来定义管道。

今天，IMO几乎没有理由使用Job，因为管道是Jenkins支持的用于编写Jenkins管道的机制，它已经满足或超过了Job的大部分功能。新的插件正在为管道开发，而那些没有被Jenkins开发人员鼓励与管道集成的插件。管道有几个优点：

• 没有必要像使用作业DSL那样使用管道“播种”作业，因为管道本身就是作业。使用jobs，它只是一个创建其他作业的脚本。
• 使用管道，您有一些特性，例如参数化的手动输入步骤，允许在管道中指定逻辑流。
• 可以包含在作业DSL中的逻辑仅限于创建作业本身；而使用管道，则可以将逻辑直接包含在作业中。
• 简单地说，使用构建管道插件创建一个基本的传递管道要困难得多；使用管道，您的文件将更小，语法也会更短。如果您正在使用jobs来创建管道工作，那么考虑到Jenkins管道的模板特性，我再也看不到它的主要价值了。

最后，詹金斯管道是目前詹金斯最普遍的特点。查看詹金斯2016年世界议程，您将看到大约。50%的会议涉及管道。没有工作DSL。

Answer 2

我的感觉是，理想的方法是两者兼用。管道是将作业作为代码的新的本地Jenkins特性。然而，如果从零开始建造Jenkins，那么仍然需要创造这些就业机会。这意味着Jenkins不可能100%地编写脚本并由代码构建。

您可以做的是使用作业DSL来构建所有作业的骨架结构，然后使用管道来实现作业。这将允许您100%编写Jenkins脚本，减去要创建的初始种子作业。

也许，最终我们将能够使用管道完全控制Jenkins (安全，配置，甚至插件)。但在此之前，我认为使用DSL和管道是一种很好的方法。

Answer 3

根据有限的经验，我的初步答覆如下：

• 每一个都使用不同的Groovy。
• jobs为您提供了一种根据Groovy脚本创建其他工作的方法。因此，如果您想要一组与X相关的作业(例如，一个管道)，您将创建一个jobs作业，编写脚本，运行该作业，然后您将得到那些X作业，再加上创建这些作业的那个作业。此时，只有您直接创建的作业已经运行，而由该作业创建的作业还没有运行。OOTB，这些作业并不像隐藏多模块Maven作业中的Maven模块那样被隐藏，但我知道至少有一种方法可以创建视图并将作业固定在那里。
• 管道DSL只是无限期挂在两个非常不同的环境中，我已经尝试过了。：(据我所知，这是一个已知的防显示错误--搜索，你会在上面找到一些打开的臭虫票。不管是谁，运行您创建的管道作业实际上都运行管道，而不是生成像jobs这样的作业。因此，运行管道作业的触发器是运行管道的触发器，而不仅仅是更新它定义的作业。
• 从下载的数量来看，管道的使用似乎更加广泛。当然，管道是Jenkins 2.0的默认特性，这可能是最近下载量激增的原因。Jenkins 当然想让你用它的维护人员。

因此，综上所述: jobs的DSL是用来创建形成管道的就业机会的，管道插件的DSL定义了管道本身。

为了回答您的问题:管道应该在将来得到更广泛的支持，在我看来更直接(这个任务是一个任务，而不是一个元作业)，并且似乎有更多的特性(包括工作流)。我会使用它，除非您点击前面提到的doom的显示停止错误，并且找不到一个修复/解决方法。