|
||||||||
|
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.
I have to wholeheartedly agree with surya et al: There needs to be a (non-plugin) switch for this. Perhaps not a global switch (although, why not?), but at an absolute minimum a per-job switch. This is a Jenkins-wide issue and giving plugins enough rope to hang the users does not strike me as the best process.
The only "workaround" really is to throw out the entire Post-Build functionality and recreated it from whole cloth as Build Steps. That is really what this bug means: The entire Post-Build feature must be considered suspect and unreliable. At the very minimum there should be a huge user warning around the Concurrent Build check box telling users that Post-Build actions may likely serialize their jobs anyway and should be avoided.
It should also be noted that Jenkins jobs are leveraged for MUCH more than simply "pulling code from an SCM and compiling it" type jobs. There are a huge number of utility tasks around a typical development lifecycle (deployments, environment setups and refreshes, data jobs, etc) that fit very well into Jenkins. In the real world I see such utility jobs far, far outnumber "real" build jobs. I mention this because of all the debate above about Git vs Subversion workflows and the like: It doesn't matter...in real world Jenkins usage it's common to find that MOST jobs aren't calling SCM at all because they aren't "buliding" anything, rendering all such workflow debates mute.