来自 YAML 文件的 Jenkins 管道答案

【问题标题】：Jenkins pipeline from YAML file来自 YAML 文件的 Jenkins 管道
【发布时间】：2020-05-08 00:53:01
【问题描述】：

Jenkins 声明式管道对我们来说太强大了，用户经常会滥用它。我们正在考虑使用自以为是的 YAML 来描述 CI/CD 管道。而且似乎有两种选择。

编写插件并使用 YAML 并动态创建阶段/步骤。
编写一个插件来将 YAML 转换为 Jenkins 管道。

我不是 Jenkins 方面的专家，所以我希望有专家可以提供一些指导，也许可以举个例子。

【问题讨论】：

你不需要写插件。您可以使用evaluate() 在共享库中创建整个管道。 Example.
由于过去的 GSOC 项目，该插件已经存在：jenkins.io/blog/2018/07/17/simple-pull-request-plugin。
很高兴了解这两种解决方案。
您不需要使用评估。如果您想在未来对管道进行 lint，使用它还会阻止您在评估的管道上应用 Codenarc 的 linting

标签： jenkins yaml jenkins-pipeline jenkins-groovy jenkins-declarative-pipeline

【解决方案1】：

使用官方插件pipeline-as-yaml，但语法固定。
使用或自定义wolox-ci
创建您自己的共享库。然而，它们从一开始就很容易，但广泛使用时需要完整的语法设计。这是一个基于curry的伪代码。

// create a file named yamlCompiler.groovy in shared library,
def call(str){
  def rawMap = readYaml(text: str)
  // consume yaml and get a lambda function
  return {
    stage{
      steps.each{it ->
        it."$type"(it)
      }
    }
  }
}

在您的 jenkinsfile 代码块中使用 yamlCompiler。

@Library('your libs name')
def str = 
'''
steps:
 - type: sh
   script: ls -la 
 - type: echo
   message: xxx
'''
Closure closure = yamlCompiler(str)
closure.call()

【讨论】：

【解决方案2】：

我正在寻找类似的解决方案。我们为每个项目运行强化的预定义管道，但仍希望允许开发团队自定义流程中的某些步骤——而不是让他们充分利用 Jenkinsfile 的功能。

我也在探索——用你的话来说——“有意见的 YAML”。

到目前为止，我只找到了一个这样的实现示例：Wolox-CI 通过 YAML 支持他们自己的预定义构建步骤。您将能够看到他们支持的步骤here。

我正在考虑使用 Snake YAML 解析 YAML。 Here's an SO answer 以示例说明如何操作。

【讨论】：

【解决方案3】：

两种解决方案：

创建一个共享库来抽象实际管道并向您的用户提供有关如何设置共享库和 Jenkinsfile 示例的一些指导。这是嵌入式管道的示例https://github.com/SAP/jenkins-library/blob/master/vars/piperPipeline.groovy
使用其他工具，例如https://drone.io/

如果您不是专家并且不想/没有时间成为专家，那么第二种解决方案可能是最好的。

【讨论】：

【解决方案4】：

真的吗？执行插件时唯一的区别是这里吗？：

编写插件并使用 YAML 并动态创建阶段/步骤。
编写插件以将 YAML 转换为 Jenkins 管道。

请原谅我，因为我可能有点僵硬，但是抽象一个层用于动态创建声明性或脚本化的 Jenkinsfile 以简单的 groovy lang 语法编写，以便它可以在 yml 中漂亮地打印，这会阻止用户究竟如何更新你的 yml？在我看来，您的抽象只会增加您希望实现可用性的复杂性。

一，当前所有 Jenkins 的 yml 插件都是这样做的。第二，通过实现 Jenkins 域中已经可用的 groovy/(java) 类（引用 DSL），它们实际上并没有完整的“特性”（是的，我在这里松散地使用这个术语）。目前有两种解决方案，我对这两种方法都进行了调查，并广泛实施了这两种方法。一个是wolox-ci，是两者中的佼佼者，另一个是Pipeline-as-YAML。在我看来，它很容易使用，但两者都缺乏仅使用 groovy 提供的全部实现功能。那为什么要强迫呢？简单地说，您的用户可以拥有一个打印精美的 yml 文件，而不必关心简单的语法，您声称这会强化您的基础架构即代码后端，以便相同的用户不会搞砸它？对不起，我在这个断言上叫 Bull Pucky。有什么方法可以阻止任何人通过将更改推送到 yml 文件来完全搞砸你的构建，这会破坏与 groovy 的集成，或者更糟的是，完全改变你努力定制的算法？

对不起，我只是不明白。当然，使某些东西更具人类可读性总是一件好事。但是，因为您规定的原因而这样做是没有意义的。此外，除非您在 CI/CD 流程中定义了一个超级简单的算法，并且没有实现任何非连续传递式转换方法，否则使用 yml-as-Jenkinsfile-templates 插件的当前迭代可能不是你想走的路。

现在，您可以编写自己的插件来执行此操作，但与仅仅学习 groovy 语法相比，它的技术债务是什么？此外，它仍然不会阻止用户对您的构建基础架构进行代码更改，然后将这些更改集成到一个简单的 yml 文件中。

【讨论】：