Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19802

Conditional Build Step for "Current build status" never triggers - or doesn't seem to

    XMLWordPrintable

Details

    Description

      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.

      EDIT:
      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".

      Attachments

        Issue Links

          Activity

            chr0n1x Kevin R. added a comment -

            hello?

            chr0n1x Kevin R. added a comment - hello?

            can you add a simple screenshot to show your config?

            domi Dominik Bartholdi added a comment - can you add a simple screenshot to show your config?

            I don't realy know how you configured your job, but here are some examples: https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin

            domi Dominik Bartholdi added a comment - I don't realy know how you configured your job, but here are some examples: https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin
            chr0n1x Kevin R. added a comment -

            Sorry for the late response! Thanks for any info, please let me know if Im doing anything stupid.

            http://i.imgur.com/qL5n1Je.jpg

            chr0n1x Kevin R. added a comment - Sorry for the late response! Thanks for any info, please let me know if Im doing anything stupid. http://i.imgur.com/qL5n1Je.jpg

            OK, I I can reproduce it - but to be honest, I think there is a conceptional problem with the idea of this "Condition".
            If a build step fails, the next steps do never have a chance to get a hand on the build again, so the conditional build step never gets called itself and therefore he can not make any decision on whether he should trigger anything or not (this in in the core of Jenkins).

            So for what I can see right now, the "Current build status" is not of much value.

            domi Dominik Bartholdi added a comment - OK, I I can reproduce it - but to be honest, I think there is a conceptional problem with the idea of this "Condition". If a build step fails, the next steps do never have a chance to get a hand on the build again, so the conditional build step never gets called itself and therefore he can not make any decision on whether he should trigger anything or not (this in in the core of Jenkins). So for what I can see right now, the "Current build status" is not of much value.
            oleg_nenashev Oleg Nenashev added a comment -

            Kevin,

            As a workaround, you can invoke post-failure build steps from "Flexible publish" post-build action.

            oleg_nenashev Oleg Nenashev added a comment - Kevin, As a workaround, you can invoke post-failure build steps from "Flexible publish" post-build action.
            chr0n1x Kevin R. added a comment -

            Hey Oleg!
            I just updated the build configuration. I'll let you know how it goes.

            chr0n1x Kevin R. added a comment - Hey Oleg! I just updated the build configuration. I'll let you know how it goes.
            chr0n1x Kevin R. added a comment -

            Hey Oleg,

            Trying to use the Flexible Publish, the post-build step only gets triggered for the entire build as opposed to for each matrix configuration. I've tried using the "Condition for Matrix Aggregation" options, which seems to do that. Switching it off doesn't seem to yield any different result.

            Not sure what to do at this point.

            chr0n1x Kevin R. added a comment - Hey Oleg, Trying to use the Flexible Publish, the post-build step only gets triggered for the entire build as opposed to for each matrix configuration. I've tried using the "Condition for Matrix Aggregation" options, which seems to do that. Switching it off doesn't seem to yield any different result. Not sure what to do at this point.
            oleg_nenashev Oleg Nenashev added a comment -

            @Kevin, I cannot reproduce your issue. Could you attach the latest configuration of your build?

            oleg_nenashev Oleg Nenashev added a comment - @Kevin, I cannot reproduce your issue. Could you attach the latest configuration of your build?

            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?

            micxer Michael Weinrich added a comment - 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?
            srehman Sajajd Rehman added a comment -

            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

            srehman Sajajd Rehman added a comment - 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
            wolf paolo mazzoni added a comment -

            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.

            wolf paolo mazzoni added a comment - 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.

            domi Dominik Bartholdi added a comment - 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.
            wolf paolo mazzoni added a comment -

            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

            wolf paolo mazzoni added a comment - 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
            piscessmith Lance Smith added a comment -

            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 Lance Smith added a comment - 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"

            domi Dominik Bartholdi added a comment - 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"?

            micxer Michael Weinrich added a comment - 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"?
            domi Dominik Bartholdi added a comment - - edited

            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

            domi Dominik Bartholdi added a comment - - edited 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.

            micxer Michael Weinrich added a comment - Sorry, you are right. Thanks for looking into this again.

            People

              domi Dominik Bartholdi
              chr0n1x Kevin R.
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: