web-dev-qa-db-ja.com

Jenkinsのスクリプト化されたパイプラインまたは宣言的パイプライン

私は私の古いスタイルのプロジェクトベースのワークフローをJenkinsベースのパイプラインに変換しようとしています。確認しながら docsscriptedとdeclarativeという2つの異なる構文があることがわかりました。 Jenkins web declarativeシンタックスリリースなど（2016年末）。新しいシンタックスリリースがありますが、Jenkinsはまだスクリプトシンタックスもサポートしています。

今、私はどちらの状況でこれらの2つのタイプのそれぞれが最もよく一致するかどうかわかりません。 scriptedの構文はもうすぐ廃止予定ですか？それではdeclarativeはJenkinsパイプラインの将来になるのでしょうか？

これら2つの構文タイプについていくつかの考えを共有できる人なら誰でも。

jenkinscontinuous-integrationjenkins-pipeline
64
Nayana Adassuriya

Jenkins Pipelineが最初に作成されたとき、Groovyが基盤として選ばれました。 Jenkinsは長い間、管理者とユーザーの両方に高度なスクリプト機能を提供するために、組み込みGroovyエンジンを同梱してきました。さらに、Jenkins Pipelineの作成者は、Groovyが現在「スクリプト化されたPipeline」DSLと呼ばれるものを構築するための強固な基盤であることを確認しました。

Scripted Pipelineは、フル機能のプログラミング環境であるため、Jenkinsユーザーに非常に大きな柔軟性と拡張性を提供します。 Groovyの習熟曲線は、通常、特定のチームのすべてのメンバーにとって望ましいものではないため、宣言型パイプラインは、Jenkins Pipelineを作成するためのより単純で説得力のある構文を提供するために作成されました。

この2つは、どちらも基本的に同じPipelineサブシステムの下にあります。どちらも「Pipeline as code」の永続的な実装です。どちらもPipelineに組み込まれている、またはプラグインによって提供されているステップを使用することができます。どちらも共有ライブラリを利用できます

しかし、それらが異なるところは構文と柔軟性にあります。宣言は、より厳密で事前定義された構造でユーザーに利用可能なものを制限し、それをより単純な連続配信パイプラインに理想的な選択にします。 Scriptedは、Pipeline固有のシステムではなく、構造と構文に対する唯一の制限がGroovy自身によって定義される傾向がある限り、ごくわずかな制限しか提供していないので、パワーユーザーやより複雑な要件を持つシステムにとって理想的な選択です。その名前が示すように、宣言的パイプラインは宣言的プログラミングモデルを推奨します。スクリプトパイプラインは、より命令型のプログラミングモデルに従います。

からコピーされた https://jenkins.io/doc/book/pipeline/syntax/#compare

57
Nayana Adassuriya

もう1つ考慮すべきことは、宣言型パイプラインには script（）ステップ があることです。これにより、スクリプト化されたパイプラインを実行できます。だから私のお勧めは宣言的なパイプラインを使うことでしょう、そしてもし必要ならスクリプト化されたパイプラインのためにscript()を使うことです。したがって、あなたは両方の世界の長所を手に入れます。

31
CodyK

宣言型はより将来性のある選択肢であり、人々が推奨する選択肢のようです。それはビジュアルパイプラインエディタがサポートできる唯一のものです。検証をサポートしています。ほとんどの場合、スクリプト化されたスクリプトに戻ることができるので、スクリプト化されたパワーの大部分を持つことになります。時には誰かが宣言的にやりたいことができないというユースケースを思いつくことがありますが、これは一般的にしばらくの間スクリプトを使用してきた人々であり、これらの機能のギャップは間に合うでしょう。

より多くのコンテキスト： https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

13
burnettk

私は最近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を含むサンプルポッドテンプレート。

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
9
eamon1234

Jenkinsのドキュメントでは、両方の種類について適切に説明し比較しています。

「スクリプト化されたPipelineはJenkinsユーザーに非常に大きな柔軟性と拡張性を提供します。Groovyの習熟曲線は通常、特定のチームのすべてのメンバーにとって望ましいものではありません。 Jenkins Pipelineのオーサリング.

この2つは、基本的にその下にある同じPipelineサブシステムです。」

ここでもっと読んでください： https://jenkins.io/doc/book/pipeline/syntax/#compare

6
Baghel