Jenkinsのさまざまなダウンストリームビルドで統合テストを動的にトリガーしたいと考えています。テスト名をパラメーターとして受け取る、パラメーター化された統合テストプロジェクトがあります。 gitリポジトリからテスト名を動的に決定します。
Jenkins-cliを使用して、ソースコードで見つかった各テストの統合プロジェクトのビルドを開始する親プロジェクトがあります。親プロジェクトと統合プロジェクトは、一致するフィンガープリントを介して関連付けられます。
このアプローチの問題は、集計テスト結果が機能しないことです。問題は、「ダウンストリーム」統合テストがjenkins-cliを介して開始されるため、jenkinsがダウンストリームであることを認識しないことだと思います。
これを機能させるために、多くのjenkinsプラグインを調べました。結合およびパラメーター化トリガープラグインは、プロジェクトの静的リストがビルドされることを期待しているため、役に立ちません。パラメータの任意のリストを作成するファクトリがないため、ParameterizedTriggerで使用できるパラメータファクトリも機能しません。 LogTriggerプラグインは機能しません。
Groovy Postbuildプラグインは機能するように見えますが、それからビルドをトリガーする方法がわかりませんでした。
def job = hudson.model.Hudson.instance.getJob("job")
def params = new StringParameterValue('PARAMTEST', "somestring")
def paramsAction = new ParametersAction(params)
def cause = new hudson.model.Cause.UpstreamCause(currentBuild)
def causeAction = new hudson.model.CauseAction(cause)
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction)
これが最終的に私のために働いたものです。
注: パイプラインプラグイン はこの質問を無意味にするはずですが、インフラストラクチャを更新する機会がありませんでした。
ダウンストリームジョブを開始するにはなしパラメータ:
job = manager.hudson.getItem(name)
cause = new hudson.model.Cause.UpstreamCause(manager.build)
causeAction = new hudson.model.CauseAction(cause)
manager.hudson.queue.schedule(job, 0, causeAction)
ダウンストリームジョブを開始するにはwithパラメータ、ParametersAction
を追加する必要があります。 Job1
にパラメータA
とC
があり、デフォルトでそれぞれ「B」と「D」になっているとします。つまり:
A == "B"
C == "D"
Job2
に同じAパラメータとBパラメータがありますが、デフォルトで「F」になっているパラメータE
も取ります。 Job1
の次のビルド後のスクリプトは、そのA
パラメーターとC
パラメーターをコピーし、パラメーターE
をA
とC
の値の連結に設定します。
params = []
val = ''
manager.build.properties.actions.each {
if (it instanceof hudson.model.ParametersAction) {
it.parameters.each {
value = it.createVariableResolver(manager.build).resolve(it.name)
params += it
val += value
}
}
}
params += new hudson.model.StringParameterValue('E', val)
paramsAction = new hudson.model.ParametersAction(params)
jobName = 'Job2'
job = manager.hudson.getItem(jobName)
cause = new hudson.model.Cause.UpstreamCause(manager.build)
causeAction = new hudson.model.CauseAction(cause)
def waitingItem = manager.hudson.queue.schedule(job, 0, causeAction, paramsAction)
def childFuture = waitingItem.getFuture()
def childBuild = childFuture.get()
hudson.plugins.parameterizedtrigger.BuildInfoExporterAction.addBuildInfoExporterAction(
manager.build, childProjectName, childBuild.number, childBuild.result
)
GroovyPostbuildプラグインの$JENKINS_HOME/plugins/parameterized-trigger/WEB-INF/classes
にAdditional groovy classpath
を追加する必要があります。
このGroovyスクリプトを実行します
import hudson.model.*
import jenkins.model.*
def build = Thread.currentThread().executable
def jobPattern = "PUTHEREYOURJOBNAME"
def matchedJobs = Jenkins.instance.items.findAll { job ->
job.name =~ /$jobPattern/
}
matchedJobs.each { job ->
println "Scheduling job name is: ${job.name}"
job.scheduleBuild(1, new Cause.UpstreamCause(build), new ParametersAction([ new StringParameterValue("PROPERTY1", "PROPERTY1VALUE"),new StringParameterValue("PROPERTY2", "PROPERTY2VALUE")]))
}
あるビルドから別のビルドにプロパティを渡す必要がない場合は、ParametersActionを削除するだけです。
スケジュールしたビルドには、最初のビルドと同じ「原因」があります。これは、「変更」を渡すための優れた方法です。これが必要ない場合は、関数呼び出しで新しいCause.UpstreamCause(build)を使用しないでください。
すでにダウンストリームジョブを動的に開始しているので、それらが完了するまで待って、テスト結果ファイルを親ワークスペースにコピーします(ダウンストリームジョブにアーカイブしてから、「ビルド」アーティファクトをダウンロードします)。テストプラグインが複数のテスト結果ページで機能するかどうかによっては、ファイルを手動で集約する必要がある場合があります。親ジョブのビルド後のステップで、適切なテストプラグインを構成します。
これは、「システムgroovyスクリプトの実行」を使用して機能しました
import hudson.model.*
def currentBuild = Thread.currentThread().executable
def job = hudson.model.Hudson.instance.getJob("jobname")
def params = new StringParameterValue('paramname', "somestring")
def paramsAction = new ParametersAction(params)
def cause = new hudson.model.Cause.UpstreamCause(currentBuild)
def causeAction = new hudson.model.CauseAction(cause)
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction)
Groovy Postbuildプラグインを使用すると、おそらくこのようなものが機能します(まだ試していません)
def job = hudson.getItem(jobname)
hudson.queue.schedule(job)
両方のジョブをフィンガープリントすると(たとえば、親ジョブのBUILD_TAG変数を使用して)、集計された結果が取得されないことに実際に驚いています。私の理解では、ジェンキンスは単にmd5sumsを調べてジョブを関連付けます( ダウンストリームテスト結果の集計 そしてCLIを介したトリガーは結果の集計に影響を与えないはずです。どういうわけか、アップストリーム/ダウンストリームの関係を維持するために何か追加が行われています。私は気づいていません...