Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
Jenkins 1.654
Ubuntu Linux
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
- is duplicated by
-
-
- Closed
-
- is related to
-
JENKINS-26522 Annotated block/stage status
-
- Closed
-
Activity
Sam Van Oort
added a comment - dracorp 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.
Sam Van Oort
added a comment - dracorp 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.
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.
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. Sam Van Oort
added a comment - mscharp Released with v 1.6 Sam Van Oort
added a comment - Tested, reviewed and merged - goes live with next release. 
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...