I have a similar problem, that might be related: We have a long running job so we decided to only start it when someone manually triggers it, the code changed or the last build status wasn't SUCCESS. However in the latter case the next build reports the current built status as SUCCESS and the comparison doesn't trigger. Am I thinking the wrong way how this condition is supposed to work or is this actually a bug?

Ok nor sure it will be relevant here but I spent quite a few hours debugging it and in the end it turned out to be super condition at the bottom saying "Execute script only if build succeeds" was causing issue. This box (Execute script only if build succeeds)is checked by default. unchecked that and now conditional steps work as expected. Though I might be having totally different issue then described here

I agree with Dominik, it's very strange to watch the build status, but I find it useful when executing external programs or batches, for example sql scripts. With oracle it is possible to interrupt script execution with the clause 'WHENEVER SQL ERROR EXIT FAILURE', this immediately stops script execution and puts the build in failure status. In this case I would watch for the build status and flashback the whole instance (flashback supported since oracle 10.2 btw), but with the bug above mentioned it is long and complicated to manage and identify this situation.

sorry, maybe I was not clear enough...
The conditional-buildstep plugin is not able to fix this issue. Jenkins stops triggering any further buildsteps if the current build status is not SUCCESS - therefore conditional-buildstep is not able to validate the status either.
From a conceptional point of view, everything depending on the buildstatus has to be solved/triggered in a post build action, so "Flexible publish" plugin is the one you have to use.
The condition "Current build status" should be removed in one of the next releases of the conditional buildstep plugin.

Well the "Current build status" condition resulted confusing to me since I read it for the first time, so I'll write a post build action as suggested

This used to work and got broken somewhere along the way
It would be REALLY nice if we got it back.
The scenerio I have is we do allot of cross compileing for both MIPS and ARM archetitectures. We there-for have to use their supplied compilers for the the embeded device. We have a very rare, you can tell I just discoverd this, accurence where one of the compilers actually will swap 2 bytes in one very necessary binary. I can catch it using a md5sum against the newly compiled binary compared to an old valid one. When this happens I just need to restart the job from the beggining and it goes away.
As this job runs at night and normally takes a little over 1.5 hrs it is nice to have it restart automatically before having to-do it by hand in the morning.

Another example of how this would be used is contained here http://architects.dzone.com/articles/conditional-buildstep-jenkins. There
are many others also available.

If this was broken by something at a higher level please let me know who to contact to try and get this fixed.

THANKS for you hard work on this great product.

piscessmith as mention above, this can not be fixed in this plugin and its also very unlikely to be fixed anywhere else in the core. From a conceptional point of view the current behaviour is correct and you should not be using the build status.

I would suggest you take a look at the workflow plugin, then you might be able to work around the issue by using more advanced configurations with "try/catch/finally"

I'm ok with it being the wrong approach, but why not remove that option altogether to avoid question/bug reports like these? Wouldn't that make more sense instead of just closing it as "Won't fix"?

because the conditions are part of a different plugin https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin and not as such under controll of the conditional buildstep plugin

...I see if I can make it configurable

Sorry, you are right. Thanks for looking into this again.