-
New Feature
-
Resolution: Fixed
-
Major
-
None
Sometimes I want to be able to block the execution of the current build until the completion of the remote build. In this case, I also want to decide whether the current build should be marked as failed in case the remote build failed or if it should just ignore it and continue.
Hint: the async-http-client is a shared lib plugin which might help you to implement this: https://wiki.jenkins-ci.org/display/JENKINS/Async+Http+Client+Plugin
[JENKINS-20828] Allow to block the build untill target job finished
I would be interested in a solution to this.
I don't know how much access to have to the job you create on the other server, but if you could add an object to the job that has a unique ID in it you can map this back to the job that called it?
I have created a workaround/fix for this issue. My code does the following:
- get the nextBuildNumber from the job
- trigger the build
- check that next build number has increased by one - this means we know that the only job triggered is the one we triggers, otherwise we error
- then wait for the job with the build number above to start
- then wait for the job with the build number above to finish and return the result.
I can share the code if you are interested
*I also split out the HTTPRequest code into a method, so you can call different URLs with different methods (to simplify the communication with the remote server).
I do agree however, it would be a lot easier if the trigger call returned the build number of the job it's just triggered. Could raise an issue to see if this can be done?
Maurice W.
added a comment - Yes! I would love to see some code for this.
Do you have an available fork on Github? If not, could you create a gist (http://gist.github.com) showing the functionality you mentioned above.
Maurice W.
added a comment - Yes! I would love to see some code for this.
Do you have an available fork on Github? If not, could you create a gist ( http://gist.github.com ) showing the functionality you mentioned above. I tried checking into github and it returned me a 403. I have it in a branch I can commit if you like?
I have added the code I ahve changed to the gist - not sure I've done it right, but I can updated if required - got to rush out atm 
.
Maurice W.
added a comment - Can you paste a link to the gist you created? Maurice W.
added a comment - Could you please submit a Pull Request on GitHub for the changes you want to see merged back into the plugin and released.
Maurice W.
added a comment - Could you please submit a Pull Request on GitHub for the changes you want to see merged back into the plugin and released.
Thanks for the tip.
The tricky part with this will be trying to figure out when the actual build starts on the remote server.
Because build numbers are assigned when the build starts (not when it's scheduled) I am yet to find a way to accurately identify the newly scheduled build.
Currently I triggering the remote job with delay=0, which in theory should move that build to the top of the queue (I think?). But I need to do more testing with a "busy" job to confirm.