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

我正在尝试将旧式项目基础工作流转换为基于Jenkins的管道.在浏览文档时,我发现有两种不同的语法命名scripted和declarative.比如declarative最近的Jenkins web 语法发布(2016年底).虽然有一个新的语法版本,但Jenkins仍然支持脚本语法.

现在,我不确定这两种类型中哪一种最适合.scripted语法很快就会被弃用？那么declarativeJenkins管道的未来会是什么？

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

1> Nayana Adass..：

---

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

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

这两个基本上都是下面的Pipeline子系统.它们都是"Pipeline as code"的持久实现.他们都能够使用Pipeline内置的步骤或插件提供的步骤.两者都能够使用共享库

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

复制自https://jenkins.io/doc/book/pipeline/syntax/#compare

---

@cauchy对于脚本化和声明性管道都有相同的文档，但是由于脚本化是针对高级用户的，因此它不是首先显示的，而是所有文档都具有脚本化和声明性管道文档和示例。您只需要在声明性管道的每个文档示例下面切换编码语法即可

---

我试图将一系列声明性管道作业移至脚本化管道，因为它们“对于高级用户和要求更复杂的用户是理想的选择”。脚本化管道的文档几乎为零。没有。这样几乎没用。人们应该意识到这是一个很大的差异。

2> CodyK..：

---

另一件需要考虑的事情是声明性管道有一个script()步骤.这可以运行任何脚本化管道.所以我的建议是使用声明性管道,如果需要,可以使用script()脚本化管道.因此,您将获得两全其美.

---

您是否有在声明式管道中使用script（）块的示例？该链接没有任何内容。

3> eamon1234..：

---

我最近从使用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

4> burnettk..：

---

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

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

---

如这里的其他多个答案所述，没有什么可以更适应未来的需求了，它们服务于不同的受众和目的，并且两者具有相同的基础系统。声明式限制用户，脚本给他们太多的自由，因此您需要使用不同的詹金斯知识水平才能应用每种知识。

---

我同意你的看法。这个答案在我写这篇文章的时候是最好的，但是我很高兴詹金斯的作者现在更好地记录了这些差异，并明确指出脚本不会很快消失。:)

5> 小智..：

---

Jenkins文档正确地解释并比较了这两种类型.

引用:"Scripted Pipeline为Jenkins用户提供了极大的灵活性和可扩展性.对于给定团队的所有成员来说,Groovy学习曲线通常并不理想,因此创建Declarative Pipeline是为了提供更简单,更具见解性的语法.创作詹金斯管道.

这两者基本上都是下面的管道子系统."

在这里阅读更多内容:https://jenkins.io/doc/book/pipeline/syntax/#compare