Jenkinsfileにプロパティのみを含め、パイプラインコードを含めることはできませんか

debugcn 投稿 Dev

Asif Kamran Malick

宣言型パイプラインの作成に関して私が遭遇したすべてのチュートリアルは、Jenkinsfileにステージとステップを含めることを提案しています。

しかし、私は先輩の一人がそれを反対の方法で書いていることに気づきました。彼はすべてのプロパティを定義するためだけにJenkinsfileを使用します。つまり、彼のJenkinsfileは単なるプロパティファイルであり、それ以上でもそれ以下でもありません。

そして、パイプラインを定義するために、彼は共有ライブラリの概念を利用して、varsフォルダー内のファイルにパイプラインコードを書き込みます。このアプローチの背後にある知恵を推測することはできません。

インターネットのどこにも似たようなものはありませんでした。
この点に関するガイダンスは大歓迎です。私はジェンキンスの世界の初心者です。

VonC

共有ライブラリを使用した拡張で説明されているように、そのアプローチ（私も使用しています）では次のことが可能です。

Jenkinsfileのコンテンツを最小限に抑える
特定のジョブを実行する標準的な方法を適用する（共有ライブラリにコード化されている）

その共有ライブラリは、実際の実行を事前定義されたライブラリに委任する前に、Jenkinsfileの値のみを提供するプロセスのテンプレートになります。

OPアシフカムランマリックのことに注意してくださいドキュメントが含まれません：

Groovyを使用した「ビルダーパターン」のトリックもありますClosure.DELEGATE_FIRST。これにより、Jenkinsfileはプログラムよりも構成ファイルのように見えますが、これはより複雑でエラーが発生しやすいため、お勧めしません。

それから彼は尋ねます：

公式ドキュメントで実際に落胆したのに、なぜブロガーはその方法を好んだのですか。

確認して使用していますClosure.DELEGATE_FIRST。
その理由は、「Jenkinsfileがプログラムよりも構成ファイルのように見えることを許可する」という部分にあります。

これにより、JSONブロックを定義する必要がなくなり、パラメーターを一連のkey=value行として保持し、読みやすくなります。

共有ライブラリへの呼び出しは次のようになります。

#!/usr/bin/env groovy
@Library("MyLibraries") _
MyLibrary {
    config1 = 'value1'
    config2 = 'value2'
    ...
}
{
    anotherConfigA = 'valueA'
    anotherConfigB = 'valueB'...
    astep(
        ...
    )
}

次に、のjenkinsパイプラインテンプレートでMyLibraries/vars/MyLibrary.ymlこれらのクロージャーブロックを使用できます。

def call(Closure configBlock, Closure body) {
    def config = [:]
    configBlock.resolveStrategy = Closure.DELEGATE_FIRST
    configBlock.delegate = config
    configBlock()

    astep(
      ...
    ){
      if (body) { body() }
    }
}

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]