|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
The problem with the parametrized-plugin-blocking-buildstep solution is also that you cannot copy artifacts, as artifact copying is only possible in the post build. This means that all the features around artifacts are lost (md5s, etc).
The solution mentioned by Kohsuke, item #2 specifically, with UpstreamCause, would unfortunately not work for me, as the Upstream cause of the build does not pass through buildFlow.
I believe one of the challenges here is what to do if the job / promotion you are waiting for never triggers ? For example, if you have some build which fails, it may not trigger downstream, and the "end" job might not happen. This means there will probably have to be a way to manually terminate the gerrit operation in case what is expected doesn't happen. Otherwise, you may end up with a lot of "open" gerrit events, waiting for jobs which may well never be triggered.
One option I have been thinking of would be to have in the post-build phase, an action:
'fail/approve the triggering Gerrit event with ID: ', and allow a parameter. You would have to pass the Gerrit-event ID via build parameters for instance, but parameters are very well supported. This is sufficiently flexible for most use-cases I believe. optionally, we could even imagine: