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

          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-35474 Conditional step in post step of Maven Project run despite of result of build step

          • Major - Major loss of function.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-52609 Conditional step not getting executed even when build step failed and both worst step and best step are marked as failed

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 14 older comments
            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.
            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"

            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"
            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"?

            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
            micxer Michael Weinrich added a comment -

            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: