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.

Piotr Zegar
added a comment - 2016-07-30 09:05 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 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.

Sam Van Oort
added a comment - 2016-07-30 16:00 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.

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...

Piotr Zegar
added a comment - 2016-07-30 16:11 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...