|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
I can't comment on whether or not this is "working as designed" as I've never seen any design specifications for Jenkins, but if this is the case then it simply means that this is a design fault instead of a coding fault. It's stil a fault, it's just that the "finger of blame" points at the design/algorithm instead of the coding itself.
e.g. I've got a build "A" that creates a library, and a build "B" which consumes that library and provides a second library, and a build "C" which consumes both of those.
How do I tell Jenkins not to build C until after B has built, and not to build B until after A has finished building, if not through this "block build when upstead is building" option (combined with the "build this one after that one" option)? That is, after all, what that "block build" functionality is intended to give me, is it not?
If Jenkins goes running builds on C after A but before B then, when C builds, C will get a mismatched A & B and may get a build failure (followed by a working build once the second build has gone through).
I /had/ rather expected that, if I told Jenkins that B depended on A, and C depended on B, and not to build either B or C "whilst an upstream build was building", then that should have stopped C from building until the builds of A and B had all settled down nicely, and this is "mostly" what happens, except for some race conditions. I don't like race conditions causing my builds to go red - I want my builds to only ever go red when there's a problem with my code, not just because Jenkins built something when it shouldn't have done.
(I have enough trouble persuading my fellow developers that red builds mean there's a problem with their code, without Jenkins causing spurious redness)
I maintain that this is a bug - I very much doubt that this is deliberate behaviour - it makes no sense as sometimes it blocks builds and sometimes it doesn't, and it's all down to timing. A build engine like Jenkins shouldn't leave behaviour down to "timing", it should be very very predictable and leave nothing to chance.
One should be able to check-in changes to the SCMs for A, B and C all at once to make a set of self-consistent changes, and then walk away and let Jenkins build A, then B, then C in that order.