Jenkins-ジョブ間で変数を渡す？

私はジェンキンスで2つの仕事をしていますが、どちらも同じパラメーターが必要です。

パラメータを使用して最初のジョブを実行し、2番目のジョブをトリガーするときに、同じパラメータが使用されるようにするにはどうすればよいですか？

パラメータ化されたトリガープラグインを使用すると、あるタスクから別のタスクにパラメータを渡すことができます。

また、アップストリームからダウンストリームに渡したこのパラメーターを追加する必要があります。

1.ビルド後のアクション> [他のプロジェクトでパラメーター化されたビルドをトリガーする]を選択します

2.値を使用して環境変数を入力します。値はJenkinsビルドパラメーターにすることもできます。

詳細な手順はここで見ることができます：-

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

お役に立てば幸いです:)

ここで受け入れられた答えは、私のユースケースでは機能しません。あるジョブでパラメーターを動的に作成し、それらを別のジョブに渡すことができる必要がありました。マークマッケナは言及ポストビルドアクションにシェルビルドステップから変数をエクスポートする方法は一見ありません。

値をファイルに書き込み、そのファイルを「ビルド後のアクションの追加」->「パラメーター化されたビルドのトリガー...」を介してインポートするパラメーターとして使用し、「パラメーターの追加」を選択することで、パラメーター化トリガープラグインを使用して回避策を達成しました。> 'プロパティファイルからのパラメータ'。

上記の答えには更新が必要だと思います。

アップストリームビルドアーティファクトを格納する動的ディレクトリを作成しようとしていたので、アップストリームジョブビルド番号をダウンストリームジョブに渡したいと思いました。上記の手順を試しましたが、機能しませんでした。仕組みは次のとおりです。

1. コピーアーティファクトプラグインを使用して、現在のジョブからアーティファクトをコピーしました。
2. アップストリームジョブのビルド後のアクションで、「SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}」のような変数を追加し、ダウンストリームジョブをトリガーするように構成しました。
3. ダウンストリームジョブが$ SOURCE_BUILD_NUMBERを取得してディレクトリを作成できなかったことを除いて、すべてが機能しました。
4. したがって、この変数を使用するには、下の図のように、ダウンストリームジョブでパラメーター変数と同じ変数を定義する必要があることがわかりました。

これは、新しいバージョンのjenkinsでは、ダウンストリームジョブでも変数を定義する必要があるためです。お役に立てば幸いです。

（仲間のグーグルのために）

Build Flow Pluginを使用して本格的なパイプラインを構築している場合は、次のようにDSLを使用してジョブ間でパラメーターを渡すことができます。

他のジョブに渡すために、使用可能な文字列パラメータ「CVS_TAG」を想定します。

build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
   // will be scheduled in parallel.
   { build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
   { build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])

利用可能な変数/パラメータを表示するためのヒント：

// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'

まだコメントできないので、NigelKirbyの回答に加えて私の回答を追加してください。

動的に作成されたパラメーターを渡すために、「シェルの実行」タイルで変数をエクスポートしてから、「他のプロジェクトでパラメーター化されたビルドをトリガーする」=>「事前定義されたパラメーター」=>「YOUR_VAR = $ YOUR_VAR」を渡すこともできます。私のチームはこの機能を使用して、ビルドジョブからデプロイメントジョブにnpmパッケージバージョンを渡します

更新：上記はJenkinsが挿入したパラメーターに対してのみ機能し、シェルから作成されたパラメーターは引き続き同じメソッドを使用する必要があります。例えば。YOUR_VAR = $ {YOUR_VAR}> variable.propertiesをエコーし​​、そのファイルをダウンストリームに渡します

pomバージョンをダウンストリームのRundeckジョブに渡さなければならなかったときに同じ問題に直面しました。

私がしたことは、プロパティファイルを介したパラメータインジェクションを使用することでした。

1）シェルを介してプロパティファイルにプロパティを作成する：

ビルドアクション：

• シェルスクリプトを実行する
• 環境変数を挿入する

例：プロパティの定義

2）定義されたプロパティをダウンストリームジョブに渡す：ビルド後のアクション：

• 他のプロジェクトでパラメーター化されたビルドをトリガーする
• パラメータの追加：現​​在のビルドパラメータ
• パラメータの追加：事前定義されたパラメータ

例：プロパティ送信

3）その後、ダウンストリームのRundeckジョブで$ POM_VERSIONをそのまま使用することが可能になりました。

/！\ Jenkinsバージョン：1.636

/！\トリガーされたビルドを作成するときに何らかの理由で、プロパティを渡すためにオプション「現在のビルドパラメーター」を追加する必要がありました。

答えを読んで、私が好きな別のオプションが見当たらないので、それも提供します。私は仕事のパラメータ化が大好きですが、それは常にうまくスケーリングするとは限りません。最初のジョブのすぐ下流ではなく、パイプラインのさらに下流にあるジョブがある場合、パラメーターを完全に渡すことができるように、パイプライン内のすべてのジョブをパラメーター化する必要はありません。または、他のさまざまなジョブで使用されるパラメーターが多数ある場合（特に、必ずしも1つの親ジョブまたはマスタージョブに関連付けられていないパラメーター）、パラメーター化は機能しません。

このような場合、プロパティファイルに値を出力してから、EnvInjectプラグインを使用して必要なジョブに値を挿入することをお勧めします。これは動的に実行できます。これは、パラメーター化されたジョブがまだ使用されている上記の別の回答からの問題を解決する別の方法です。このソリューションは、多くのシナリオで非常に適切に拡張できます。

これを行うには、HudsonGroovyビルダーを使用できます。

パイプラインの最初の仕事

パイプラインの2番目の仕事

私はそれを考え出した！

ほぼ2時間の試行錯誤で、私はそれを理解しました。

これは機能し、変数をリモートジョブに渡すために行うことです。

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2=${env.param2}")

\ nを使用して、スペースなしで2つのパラメータを区切ります。

パラメータとは対照的に： '' 'someparams' ''

paramtersを使用します： "someparams"

「...」は、目的の変数の値を取得するものです。（これらは二重引用符であり、2つの一重引用符ではありません）

'' '...' ''または '...'はこれらの値を取得しません。（3つの一重引用符または単一引用符のみ）

ここでのすべてのパラメーターは、パイプラインの開始時にenvironment {}ブロックで定義され、必要に応じてステージ>ステップ>スクリプトで変更されます。

また、テストしたところ、「...」を使用すると、「」...「...」「」や「...」..'...」などの組み合わせを使用できないことがわかりました。それ...

ここでの落とし穴は、パラメータセクションで「...」を使用している場合、文字列パラメータを渡すことができないということです。たとえば、これは機能しません：

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2='param2'")

上記のようなものを渡したい場合は、環境変数param2 = 'param2'を設定してから、リモートトリガープラグインステップのパラメーターセクションで$ {env.param2}を使用する必要があります。