I played around with this a bit, with a couple of freestyle jobs
that do nothing except sleep a while and then finish. I confirmed
that, whether I set the 'wait' property or not, both freestyle jobs
are more or less immediately triggered if they are in a parallel
block. If wait is set to true (or not set), 'build' returns a
RunWrapper
object which can be queried for build result or other things. If you
do getRawBuild() on the RunWrapper object you get a standard Run
object, with access to all Run methods such as getLog().
If wait is set to false, then indeed the pipeline job rushes on to
completion, and the waitUntil step is no help, at least the way it
is used in my example. I looked back on my use of waitUntil in the
past, and it was for a different purpose. So you do need to set
wait: true, but it does not prevent the jobs from running in
parallel. My test pipeline script is below.
Eric
node {
wrap ([$class: 'TimestamperBuildWrapper']) {
stage('Testing') {
parallel (
['windows_remote': {
winx = build \
job: 'dev_compile_win',
parameters: [string(name: 'branch_name',
value: branch_name)],
wait: true
echo 'Windows done'},
'linux_remote': {
linx = build \
job: 'dev_compile_lin',
parameters: [string(name: 'branch_name',
value: branch_name)],
wait: true
echo 'Linux done'}
]
)
echo 'Both are done!'
println "Linux result: ${linx.result}\n"
println "Windows log:"
winLog = winx.getRawBuild().getLog(20)
logOut = ''
for (i = 0; i < winLog.size(); i++) {
logOut += winLog[i] + '\n'
}
println logOut
}
}
}
--
You received this message because you are subscribed to the Google
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkinsci-use...@googlegroups.com.