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

Visualization shows stage failed when an exception is caught

    Details

    • Similar Issues:

      Description

      I have a stage with a try/catch block. It attempts to copy an artifact from a previous build. If it can't, the step throws an exception which is caught and handled. In the catch block it copies it from a different location (successfully) and my pipeline continues. However, in visualization, the stage is marked as failed. I would expect that regardless of exceptions thrown, if the stage completes successfully it should be green in visualization.

      This is the error that is thrown/caught:

      hudson.AbortException: Unable to find project for artifact copy: null
      This may be due to incorrect project name or permission settings; see help for project name in job configuration.
      

        Attachments

          Issue Links

            Activity

            Hide
            svanoort Sam Van Oort added a comment -

            Tested, reviewed and merged - goes live with next release.

            Show
            svanoort Sam Van Oort added a comment - Tested, reviewed and merged - goes live with next release.
            Hide
            svanoort Sam Van Oort added a comment -

            Michael Scharp Released with v 1.6

            Show
            svanoort Sam Van Oort added a comment - Michael Scharp Released with v 1.6
            Hide
            clockman Piotr Zegar added a comment -

            Thank you for taking out the only way to set Success/Fail status to individual stages.
            I will stick to 1.5 until JENKINS-26522 will be implemented.

            The only thing I wanted is to run bunch of tasks from one job and see with one succeed and with one failed.

            Show
            clockman Piotr Zegar added a comment - Thank you for taking out the only way to set Success/Fail status to individual stages. I will stick to 1.5 until JENKINS-26522 will be implemented. The only thing I wanted is to run bunch of tasks from one job and see with one succeed and with one failed.
            Hide
            svanoort Sam Van Oort added a comment -

            Piotr Rogoża I'm sorry to hear that this fix broke your implementation. There are a several appropriate ways to accomplish what you're trying to do, which will be future-proof:

            • Use try/catch, and in the case of a caught error, collect a list of failures to report at the end (setting currentBuild.result to UNSTABLE at that time, so you know that there was partial failure).
            • Use parallel blocks without failfast for each case (where the components can execute concurrently). This will reduce overall runtime, as well as isolating each case. You will get an overall pass/fail/unstable for the stage containing the parallel.
            • Use subjobs for components which should have their own pass/fail statuses to report (but where you want to allow the pipeline to be able to continue).

            Any one of these will let you do what you want in one fashion or another. You are, of course, welcome to use a legacy plugin version and wait for JENKINS-26522 if you like. In general though, it isn't a great idea to make an implementation dependent on an obvious bug. While we try not to break users, responsible maintainers do have a duty to prioritize fixes for the general use case over an individual user's custom hack.

            Show
            svanoort Sam Van Oort added a comment - Piotr Rogoża I'm sorry to hear that this fix broke your implementation. There are a several appropriate ways to accomplish what you're trying to do, which will be future-proof: Use try/catch, and in the case of a caught error, collect a list of failures to report at the end (setting currentBuild.result to UNSTABLE at that time, so you know that there was partial failure). Use parallel blocks without failfast for each case (where the components can execute concurrently). This will reduce overall runtime, as well as isolating each case. You will get an overall pass/fail/unstable for the stage containing the parallel. Use subjobs for components which should have their own pass/fail statuses to report (but where you want to allow the pipeline to be able to continue). Any one of these will let you do what you want in one fashion or another. You are, of course, welcome to use a legacy plugin version and wait for JENKINS-26522 if you like. In general though, it isn't a great idea to make an implementation dependent on an obvious bug . While we try not to break users, responsible maintainers do have a duty to prioritize fixes for the general use case over an individual user's custom hack.
            Hide
            clockman Piotr Zegar added a comment -

            Well, making implementation that depend on workaround is also not great idea.
            I stick to old version because I like to see greed/red status for each stage, with new version all stages become red, but those that were red previously are darker. When using currentBuild.result that stages lose that darker color .

            As this is mainly information for me, I going to stick with current version and wait JENKINS-26522.
            With parallel task there is one problem, they don't visible directly in Stage View .
            And I like a current Stage View, nice to see specific steps build, ut, component tests, target tests, ... See how much time were needed for each stage...

            Show
            clockman Piotr Zegar added a comment - Well, making implementation that depend on workaround is also not great idea. I stick to old version because I like to see greed/red status for each stage, with new version all stages become red, but those that were red previously are darker. When using currentBuild.result that stages lose that darker color . As this is mainly information for me, I going to stick with current version and wait JENKINS-26522 . With parallel task there is one problem, they don't visible directly in Stage View . And I like a current Stage View, nice to see specific steps build, ut, component tests, target tests, ... See how much time were needed for each stage...

              People

              • Assignee:
                svanoort Sam Van Oort
                Reporter:
                mscharp Michael Scharp
              • Votes:
                5 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: