Jenkinsのスクリプト型パイプラインまたは宣言型パイプライン

私は、古いスタイルのプロジェクトベースのワークフローを、Jenkinsに基づくパイプラインに変換しようとしています。docs]1を見ていると、scriptedとdeclarativeという2種類の構文があることがわかりました。そんなJenkinsのWebのdeclarativeシンタックスのリリースは最近（2016年末）です。新しいシンタックスのリリースがありましたが、Jenkinsはまだscriptedシンタックスもサポートしています。

さて、この2つのタイプはそれぞれどのような場面でベストマッチになるのか、よくわかりません。scripted構文はもうすぐ非推奨になる？では、declarative`はJenkinsパイプラインの未来になるのでしょうか？

この2つの構文タイプについて、どなたかご意見をお聞かせください。

Vadim Kotov
編集された質問 24日 5月 2017 в 2:11
プログラミング
continuous-integration jenkins jenkins-pipeline
19日 4月 2017 в 1:55
まだビューはありません
質問へのコメント (1)
ソリューション

Jenkins Pipelineが最初に作られたとき、基盤としてGroovyが選択されました。Jenkinsは、管理者やユーザーに高度なスクリプト機能を提供するために、長い間Groovyエンジンを組み込んで出荷されてきました。さらに、Jenkins Pipelineの実装者は、現在「Scripted Pipeline" DSL」と呼ばれているものを構築するための強固な基盤として、Groovyを選択しました。

Scripted Pipelineは、完全なプログラミング環境であるため、Jenkinsユーザーに非常に多くの柔軟性と拡張性を提供します。Groovyの学習曲線は、あるチームのすべてのメンバーにとって望ましいものではないため、Jenkins Pipelineをオーサリングするための、よりシンプルで意見交換しやすい構文を提供するために、Declarative Pipelineが作られました。

この2つは、どちらも根本的には同じPipelineサブシステムの下敷きになっています。Pipelineに組み込まれたステップやプラグインが提供するステップを使用することができます。共有ライブラリを利用することができる。

しかし、両者が異なる点は、構文と柔軟性です。Declarativeは、より厳密であらかじめ定義された構造でユーザーが利用できるものを制限し、よりシンプルな継続的デリバリーパイプラインに最適な選択となります。Scriptedは、Pipelineに特化したシステムではなく、Groovy自体で定義された構造や構文の制限があるため、制限がほとんどなく、パワーユーザーやより複雑な要件を持つ人に最適な選択肢です。その名の通り、Declarative Pipelineは宣言的なプログラミングモデルを推奨しています。一方、Scripted Pipelineは、より命令的なプログラミングモデルに従います。

https://jenkins.io/doc/book/pipeline/syntax/#compare より転載

Charles
編集した答え 26日 11月 2018 в 6:09
解説 (6)

考慮すべきもう1つのことは、宣言パイプラインにscript()ステップがあることです。 これにより、スクリプト化されたパイプラインを実行できます。 したがって、私の推奨は宣言パイプラインを使用し、必要に応じてスクリプトパイプラインに「script()」を使用することです。 したがって、あなたは両方の世界の最高のものを手に入れます。

Micha Wiedenmann
編集した答え 18日 7月 2018 в 1:35
解説 (4)

最近、kubernetesエージェントでスクリプト化されたものから宣言に切り替えました。 '18年7月まで、宣言パイプラインには、キュベルネテポッドを指定する完全な機能がありませんでした。 ただし、「yamlFile」ステップを追加すると、レポのyamlファイルからポッドテンプレートを読み取ることができます。

これにより、たとえば. vscodeの優れたkubernetesプラグインでポッドテンプレートを検証し、それを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とドッカーを備えたポッドテンプレートの例。

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
解説 (1)

declarativeは、より将来性のある選択肢であり、人々が推奨するものです。Visual Pipeline Editorがサポートできる唯一のもので、検証をサポートします。そして、ほとんどのコンテキストでscriptedに戻ることができるので、結局scriptedのほとんどの力を持ちます。たまに誰かがdeclarativeでやりたいことができない使用例を思いつきますが、それはたいていscriptedを使ってきた人であり、これらの機能ギャップはそのうち解消すると思われます。

more context: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

解説 (2)

Jenkinsのドキュメントでは、両タイプを適切に説明し、比較しています。

引用します： スクリプトPipelineは、Jenkinsユーザーに非常に多くの柔軟性と拡張性を提供します。Groovyの学習曲線は、あるチームのすべてのメンバーにとって一般的に望ましいものではないので、Jenkins Pipelineをオーサリングするための、よりシンプルで意見交換しやすい構文を提供するためにDeclarative Pipelineが作られました。

この2つは、どちらも根本的には同じパイプラインのサブシステムの下敷きです&quot；

詳しくはこちら:https://jenkins.io/doc/book/pipeline/syntax/#compare

解説 (0)