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 <http://javadoc.jenkins.io/plugin/workflow-support/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.html> 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
        }
    }
}


On 3/15/2017 12:26 PM, Chris Overend wrote:
I assume you have "Block until the remote triggered projects finish their builds." = False?

  * Does it not just set your 'done' variable to true as soon as the
    remote build starts, since it does not block or wait.
  * Also with this set to False it does not get the log of the remote
    build.

--
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-users+unsubscr...@googlegroups.com <mailto:jenkinsci-users+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3870cfdc-f429-4e82-9b1f-fbf24fc0dc24%40googlegroups.com <https://groups.google.com/d/msgid/jenkinsci-users/3870cfdc-f429-4e82-9b1f-fbf24fc0dc24%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
*Eric Pyle
*
Siemens PLM Software
Lebanon, NH
+1 603-277-3060 (T)
+1 603-359-8670 (M)
eric.p...@siemens.com <mailto:eric.p...@cd-adapco.com>
http://www.siemens.com/plm <http://www.cd-adapco.com>

--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b524c57a-e387-e64e-1059-7b2100fe2824%40cd-adapco.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to