我正在尝试将旧样式的基于项目的工作流转换为基于Jenkins的管道。在浏览文档时，我发现有两种不同的语法分别命名为scripted和declarative。例如declarative最近（2016年底）发布的Jenkins网络语法。尽管有一个新的语法版本，Jenkins仍然支持脚本化语法。
现在，我不确定这两种类型在哪种情况下是最佳匹配。scripted语法将很快被弃用吗？declarative詹金斯管道的未来会是这样吗？
可以分享有关这两种语法类型的一些想法的任何人。
Answers:
最初创建Jenkins Pipeline时，Groovy被选为基础。Jenkins长期以来一直提供嵌入式Groovy引擎，以为管理员和用户提供高级脚本功能。另外，Jenkins Pipeline的实现者发现Groovy是构建现在称为“脚本管道” DSL的坚实基础。
由于它是功能齐全的编程环境，因此脚本化管道为Jenkins用户提供了极大的灵活性和可扩展性。Groovy学习曲线通常不是给定团队的所有成员所希望的，因此创建了声明式管道，以为编写Jenkins Pipeline提供更简单，更自以为是的语法。
两者基本上都在下面是相同的Pipeline子系统。它们都是“管道作为代码”的持久实现。他们都可以使用内置在Pipeline中或由插件提供的步骤。两者都可以利用共享库
但是，它们的区别在于语法和灵活性。声明性限制使用更严格和预定义的结构为用户提供的功能，使其成为更简单的连续交付管道的理想选择。脚本化脚本提供的限制非常少，以至于对结构和语法的唯一限制往往是由Groovy本身定义的，而不是由任何特定于管道的系统定义的，因此，它成为高级用户和要求更复杂的用户的理想选择。顾名思义，声明性流水线鼓励使用声明性编程模型。而脚本化管道遵循更为必要的编程模型。
要考虑的另一件事是声明性管道具有script（）步骤。这可以运行任何脚本化管道。因此，我的建议是使用声明性管道，并在需要时使用script()脚本化管道。因此，您将两全其美。
script在声明性管道中多次使用了一个块，则应考虑完全使用脚本化管道。
我最近从使用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
声明式似乎是更适合未来的选择，也是人们推荐的选择。这是Visual Pipeline Editor可以支持的唯一工具。它支持验证。它最终具有脚本的大多数功能，因为您可以在大多数情况下使用脚本。有时，有人提出用例，他们不能完全使用声明式方法完成自己想做的事情，但这通常是使用脚本已有一段时间的人，并且这些功能差距可能会随着时间而缩小。
更多上下文：https : //jenkins.io/blog/2017/02/03/declarative-pipeline-ga/
Jenkins文档正确解释并比较了两种类型。
引用：“脚本化管道为Jenkins用户提供了极大的灵活性和可扩展性。Groovy学习曲线通常不是给定团队的所有成员所希望的，因此创建了声明性管道，以提供更简单，更自以为是的语法。撰写詹金斯管道。
两者基本上都是下面的相同管道子系统。”
在此处阅读更多信息：https : //jenkins.io/doc/book/pipeline/syntax/#compare
您也可以参考此。非常好的阅读-> 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