Status: Resolved (View Workflow)
Resolution: Won't Fix
I have a multiconfiguration build with a conditional build step that is supposed to run when the build is marked as failed after an "invoke ant" step.
In the build log for each [failed] configuration I don't even see that it's checking for this condition. In the system log I see nothing too.
Sorry if I'm doing something stupid, I just have no idea where to look for the information.
It triggers for builds with SUCCESSFUL "Invoke Ant" steps before the conditional check. In the case where it is supposed to trigger, the build status AT BEST is set to "Unstable." Worst status is "FAILED".
- is duplicated by
JENKINS-35474 Conditional step in post step of Maven Project run despite of result of build step
JENKINS-52609 Conditional step not getting executed even when build step failed and both worst step and best step are marked as failed
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
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.