Question

我正在尝试将旧式项目基础工作流转换为基于Jenkins的管道。在浏览docs时，我发现有两种不同的语法scripted和declarative。例如最近的Jenkins web declarative语法发布（2016年底）。虽然有一个新的语法版本，但Jenkins仍然支持脚本语法。

现在，我不确定这两种类型中哪一种最匹配。 scripted语法很快就会被弃用？那么declarative将成为Jenkins管道的未来吗？

任何可以分享关于这两种语法类型的想法的人。

Answer 1

首次创建Jenkins Pipeline时，Groovy被选为基础。 Jenkins长期以来一直使用嵌入式Groovy引擎为管理员和用户提供高级脚本编写功能。此外，Jenkins Pipeline的实现者发现Groovy是一个坚实的基础，可以构建现在被称为＆＃34; Scripted Pipeline＆＃34; DSL。

由于它是一个功能齐全的编程环境，Scripted Pipeline为Jenkins用户提供了极大的灵活性和可扩展性。 Groovy学习曲线通常不适合给定团队的所有成员，因此创建Declarative Pipeline是为了为Jenkins Pipeline创作提供更简单，更具见解性的语法。

这两个基本上都是下面的Pipeline子系统。它们都是＆＃34; Pipeline作为代码的持久实现。＆＃34;他们都能够使用Pipeline内置的步骤或插件提供的步骤。两者都能够利用共享库

但它们的区别在于语法和灵活性。声明性限制用户可以使用更严格和预定义的结构，使其成为更简单的连续交付管道的理想选择。 Scripted提供的限制很少，因为结构和语法的唯一限制往往由Groovy本身定义，而不是任何管道专用系统，使其成为高级用户和需求更复杂的用户的理想选择。顾名思义，Declarative Pipeline鼓励声明性编程模型。脚本管道遵循更为迫切的编程模型。

从https://jenkins.io/doc/book/pipeline/syntax/#compare

复制

Answer 2

要考虑的另一件事是声明性管道有script() step。这可以运行任何脚本化管道。所以我的建议是使用声明性管道，如果需要，可以使用script()作为脚本管道。因此，你可以获得两全其美的效果。

Answer 3

声明似乎是更具前瞻性的选项，也是人们推荐的选项。它是Visual Pipeline Editor唯一可以支持的。它支持验证。它最终拥有脚本的大部分功能，因为你可以在大多数情况下回归脚本。偶尔会有人提出一个用例，他们不能完全按照声明的方式做他们想做的事情，但这通常是那些已经使用脚本一段时间的人，这些功能差距很可能会及时关闭。

更多背景信息：https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

Answer 4

我最近从使用kubernetes代理编写的脚本切换到声明式。直到18年7月，声明性管道还没有完全指定kubernetes容器的能力。但是，通过添加yamlFile步骤，您现在可以从存储库中的yaml文件中读取pod模板。

然后，您可以使用例如vscode很棒的kubernetes插件可以验证您的pod模板，然后将其读入Jenkinsfile并按照需要使用容器。

pipeline {
  agent {
    kubernetes {
      label 'jenkins-pod'
      yamlFile 'jenkinsPodTemplate.yml'
    }
  }
  stages {
    stage('Checkout code and parse Jenkinsfile.json') {
      steps {
        container('jnlp'){
          script{
            inputFile = readFile('Jenkinsfile.json')
            config = new groovy.json.JsonSlurperClassic().parseText(inputFile)
            containerTag = env.BRANCH_NAME + '-' + env.GIT_COMMIT.substring(0, 7)
            println "pipeline config ==> ${config}"
          } // script
        } // container('jnlp')
      } // steps
    } // stage

如上所述，您可以添加脚本块。带有自定义jnlp和docker的示例pod模板。

apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave:3.23-1
    imagePullPolicy: IfNotPresent
    tty: true
  - name: rsync
    image: mrsixw/concourse-rsync-resource
    imagePullPolicy: IfNotPresent
    tty: true
    volumeMounts:
      - name: nfs
        mountPath: /dags
  - name: docker
    image: docker:17.03
    imagePullPolicy: IfNotPresent
    command:
    - cat
    tty: true
    volumeMounts:
      - name: docker
        mountPath: /var/run/docker.sock
  volumes:
  - name: docker
    hostPath:
      path: /var/run/docker.sock
  - name: nfs
    nfs:
      server: 10.154.0.3
      path: /airflow/dags

Answer 5

Jenkins文档正确解释并比较了两种类型。

引用： “Scripted Pipeline为Jenkins用户提供了极大的灵活性和可扩展性。对于给定团队的所有成员来说，Groovy学习曲线通常并不理想，因此创建Declarative Pipeline是为了创作一个更简单，更具见解性的语法来创作Jenkins Pipeline

这两个基本上都是下面的Pipeline子系统。“

在此处阅读更多内容：https://jenkins.io/doc/book/pipeline/syntax/#compare

Answer 6

说明性管道在标有“管道”的块中定义，而脚本化管道在“节点”中定义。
语法-声明性管道具有“阶段”，“步骤”
如果构建失败，则声明式选项为您提供了从该阶段重新启动构建的选项，这在脚本选项中是不正确的
如果脚本编写中存在任何问题，则声明性的将在您构建作业时立即通知您，但是如果使用脚本编写，则它将通过“确定”阶段，并在“没有”阶段引发错误好吧

您也可以参考此。很好的读物-> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/2194470/szymon-stepniak?tab=profile

Answer 7

我也有这个问题，把我带到这里。声明性管道当然似乎是首选方法，我个人认为它更具可读性，但是我正尝试将中级复杂性Freestyle作业转换为声明性，我发现至少一个插件，即Build Blocker插件，即使在一个脚本块中一步也无法运行（我尝试将相应的“ blockOn”命令放到任何地方都没有运气，并且返回错误通常是“在步骤之间找不到这种DSL方法'blockOn'”）。）因此，我认为即使是脚本块，插件支持也是一个单独的问题（如果我在此方面做错了，请纠正我。）我还不得不多次使用脚本块来获得我认为的简单行为诸如设置构建显示名称的工作。

根据我的经验，我倾向于按脚本重做我的工作，因为对声明式的支持仍然不能满足我们的需求，但是很遗憾，因为我同意这似乎是最有前途的选择，而且这是正式的支持的。在做出选择之前，也许要考虑打算使用多少个插件。

Jenkins脚本化管道或声明性管道

7 个答案: