|
||||||||
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/d/optout.
I understand after some further reading:
https://issues.jenkins-ci.org/browse/JENKINS-25570
https://issues.jenkins-ci.org/browse/JENKINS-27127
That "mutex" like behavior is not really what the concurrency field is all about. It is more for filtering jobs, allowing a certain number to queue up with others effectively thrown away and failed (the secondary issue here is that it seems to hang and leave stale state).
For the benefit of others, after a bit of experimentation I've achieved what I wanted. To run parallel jobs that are similar and for some element of them the same, such that the common parts of their flow have to be serialized. Hopefully the increment below is "atomic" or at least "atomic enough".
The console noise for the waitUntil is a shame though.