|
|
|
[
Permlink
| « Hide
]
Robin Shen [04/Aug/11 01:56 AM]
Verified this is a re-introduced bug of 4.0 M1. Will get it fixed in M2.
No, no... I mean... Hmm, hard to describe.
I am triggering two steps in parallel. Due to the vagarities of the system, they both were assigned to the same host. Due to workspace locking, only one can execute at a time. So, the first one failed, and then the second one started on the same host, and also failed. Since 'cancel sibling steps' was enabled, I would have expected the second step to be cancelled when the first one failed. Can we re-open this ticket since it is not fixed yet? What do you mean by one queued for the other? Are all these parallel steps triggering other builds?
We are using 4.0.0-M1, 2011-07-02.
I just re-ran the test, and it just so happened that two of my steps were both on the same system. One queued for the other... the first one failed in under a minute, and then the second one ran on the same system (and also failed). Meanwhile, the other parallel steps (there were six in total) continued to run on other systems for another five minutes. This in spite of having the 'cancel sibling steps' option.
Please edit both steps and click the advanced setting, you will see a post execute action there. Just specify it as "Cancel sibling steps if current is failed". Then other steps will be cancelled if one step fails, and you will be able to see the whole build log.
|