Jenkins脚本化管道或声明性管道
我正在尝试将旧样式的基于项目的工作流转换为基于Jenkins的管道。在浏览文档时，我发现有两种不同的语法分别命名为scripted和declarative。例如declarative最近（2016年底）发布的Jenkins网络语法。尽管有一个新的语法版本，Jenkins仍然也支持脚本语法。
现在，我不确定这两种类型的哪种情况最合适。scripted语法将很快被弃用吗？declarative詹金斯管道的未来会是这样吗？
任何可以分享有关这两种语法类型的想法的人。
问题答案：
最初创建Jenkins
Pipeline时，Groovy被选为基础。Jenkins长期以来一直提供嵌入式Groovy引擎，以为管理员和用户提供高级脚本功能。此外，Jenkins
Pipeline的实现者发现Groovy是构建现在称为“脚本管道” DSL的坚实基础。由于它是功能齐全的编程环境，因此脚本化管道为Jenkins用户提供了极大的灵活性和可扩展性。Groovy学习曲线通常不是给定团队的所有成员所希望的，因此创建了声明式管道，以为编写Jenkins
Pipeline提供更简单，更自以为是的语法。两者基本上都在下面是相同的Pipeline子系统。它们都是“管道作为代码”的持久实现。他们俩都可以使用内置于Pipeline或插件提供的步骤。两者都可以利用共享库
但是，它们的区别在于语法和灵活性。声明性限制使用更严格和预定义的结构为用户提供的功能，使其成为更简单的连续交付管道的理想选择。脚本化脚本所提供的限制很少，以至于对结构和语法的唯一限制往往是由Groovy自己定义的，而不是由任何特定于管道的系统定义的，因此，它成为高级用户和要求更复杂的用户的理想选择。顾名思义，声明性流水线鼓励使用声明性编程模型。而脚本化管道遵循更强制性的编程模型。
从https://jenkins.io/doc/book/pipeline/syntax/#compare复制
-
我写了一个Jenkins管道，相关部分如下所示： 和我的DockerFile：
-
当我在jenkins中运行多分支管道代码时，我收到以下的以下错误： java.lang.NoSuchMethodError:在步骤中找不到这样的DSL方法“管道”[archive，bat，build，catchError，checkout，deleteDir，dir，echo，emailext，EmailExtrecients，error，fileExists，getContext，git，inp
-
问题内容： 我想使用Jenkins 2.x Groovy Script Build Pipeline开始Sonar项目分析。 我在Maven中配置了声纳，所以没什么大不了的： 但是我如何从声纳获得结果呢？甚至更好的是，我如何确定是否达到了质量要求，以便停止构建管道。 据我所知，自从某些声纳版本以来，构建破坏者的概念就已过时。或您将如何处理。 我仍然认为，如果项目的基础代码太糟糕，则停止/暂停构建管
-
我有以下管道： 不幸的是，这引发了: groovy.lang.MissingPropertyException：没有这样的属性：org.kohsuke.groovy上的类groovylang.Binding.getVariable（Binding.java:63）的master：org.jenkinsi.plugins.scriptsecurity.sandbox.groovy-SandboxIn
-
我有一个Jenkins声明性管道，我一直在Jenkins master上运行，它工作得很好。但是，现在我已经开始尝试在从属节点上执行此操作，管道中调用的groovy脚本无法访问工作区中的文件。 我的文件看起来像这样。。。 我可以在从机上看到它正在创建工作区，从git执行签出，并正确执行脚本。但是，如果脚本中的某些内容尝试与工作区中的文件交互，则会失败。 如果我有像这样简单的东西... ...它说找
-
问题内容： 我的Jenkins 2.19.4使用管道：声明式代理程序API 1.0.1。如果您无法定义变量来分配读取的属性，那么如何使用readProperties？ 例如，要捕获SVN版本号，我目前以脚本样式使用以下代码捕获它： 然后我可以使用： 由于以声明式定义svnProp是不合法的，因此如何使用readProperties？ 问题答案： 您可以使用标记内的步骤来运行任意管道代码。 所以符合