[JIRA] (JENKINS-45579) Step to set stage or parallel status

Given that ~~JENKINS-27092~~ has been closed with the intent to cover its needs on this one, I just wanted to add my need here: a simple way to abort a build while still reporting a successful status check back to GitHub (in a multibranch pipeline scenario). Right now I'm using a when condition on every stage to skip it (having detected a message like "[ci skip]" in the git commit log).

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

andrew.bayer@gmail.com (JIRA)

unread,

Feb 20, 2018, 12:10:03 PM2/20/18

to jenkinsc...@googlegroups.com

Andrew Bayer assigned an issue to Unassigned

Jenkins /

Change By:	Andrew Bayer
Assignee:	Andrew Bayer

felyppers@gmail.com (JIRA)

unread,

Mar 7, 2018, 8:40:04 AM3/7/18

to jenkinsc...@googlegroups.com

Felyppe Rodrigues commented on

I'm having similar issues due to the unreadability of the pipeline, the Devs are complaining about it. Do we have any news on this feature of setting parallel steps individual results?

jacob.keller@gmail.com (JIRA)

unread,

Mar 9, 2018, 12:44:04 PM3/9/18

to jenkinsc...@googlegroups.com

Jacob Keller commented on

This is also somewhat related to steps like the warnings publisher, which if you run in parallel results in the whole build being marked unstable even though only a single segment should have been, which may not be fixed by making separate unstable results for each parallel step (unless it fully encapsulates the build?)

vivek.pandey@gmail.com (JIRA)

unread,

Mar 13, 2018, 12:09:26 PM3/13/18

to jenkinsc...@googlegroups.com

Vivek Pandey updated an issue

Jenkins /

Change By:	Vivek Pandey
Sprint:	Pipeline - Candidates

wulfgar.pro@gmail.com (JIRA)

unread,

Mar 28, 2018, 7:48:17 PM3/28/18

to jenkinsc...@googlegroups.com

James Fraser updated an issue

Jenkins /

Change By:	James Fraser
Comment:	+1

wulfgar.pro@gmail.com (JIRA)

unread,

Mar 28, 2018, 7:48:21 PM3/28/18

to jenkinsc...@googlegroups.com

James Fraser commented on

+1

p.rogovoy@gmail.com (JIRA)

unread,

Apr 3, 2018, 8:47:03 AM4/3/18

to jenkinsc...@googlegroups.com

Pavel Rogovoy commented on

Our Dev guys are also complaining about this issue. We would like to be able to mark certain stages as unstable / failed and still continue to execute the pipeline. Then we need the ability to check for any failures of the current run and not to execute the deploy stage. What do you think?

tanguy.von.stebut@gmail.com (JIRA)

unread,

May 29, 2018, 8:05:03 AM5/29/18

to jenkinsc...@googlegroups.com

Tanguy von Stebut commented on

UP! I'd definitely be very happy to see that workint too though

nimrod7@gmail.com (JIRA)

unread,

Jul 10, 2018, 10:05:05 AM7/10/18

to jenkinsc...@googlegroups.com

Kasia Gauza commented on

What's the status of the task?

It's strange that after a year+ of trying to switch our CI from Build Flow to Pipelines/Blue Ocean, I still find the the former more usable...

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

ekassis@hotmail.com (JIRA)

unread,

Jul 26, 2018, 8:36:03 AM7/26/18

to jenkinsc...@googlegroups.com

Elie Kassis commented on

Is there any progress on this issue?

sergo27@gmail.com (JIRA)

unread,

Dec 25, 2018, 6:09:04 PM12/25/18

to jenkinsc...@googlegroups.com

Sergey Izgiyaev commented on

HI, is there any update ? We really need that feature

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

sergo27@gmail.com (JIRA)

unread,

Dec 25, 2018, 8:06:11 PM12/25/18

to jenkinsc...@googlegroups.com

Sergey Izgiyaev updated an issue

Jenkins /

Change By:	Sergey Izgiyaev
Priority:	Major Critical

paul.de-courcel@fr.thalesgroup.com (JIRA)

unread,

Jan 3, 2019, 5:40:05 AM1/3/19

to jenkinsc...@googlegroups.com

Paul de Courcel commented on

Hi ! We really need this ! No news ?

yahia.bilel@gmail.com (JIRA)

unread,

Jan 8, 2019, 9:19:03 AM1/8/19

to jenkinsc...@googlegroups.com

Bilel Yahia commented on

I'd love to see this implemented too. Is there any planned work to do it?

shanidar1@gmail.com (JIRA)

unread,

Jan 14, 2019, 7:22:06 AM1/14/19

to jenkinsc...@googlegroups.com

Shani Dar commented on

Is there any update?

driver@hotmail.co.uk (JIRA)

unread,

Apr 2, 2019, 4:56:28 AM4/2/19

to jenkinsc...@googlegroups.com

Ian Driver commented on

I also need this feature

driver@hotmail.co.uk (JIRA)

unread,

Apr 2, 2019, 4:56:28 AM4/2/19

to jenkinsc...@googlegroups.com

Ian Driver edited a comment on

I We also need this feature

jglick@cloudbees.com (JIRA)

unread,

Apr 10, 2019, 2:55:06 PM4/10/19

to jenkinsc...@googlegroups.com

Jesse Glick commented on

 
                                                                stage ('Optional Tests') {
  echo 'Running optional tests…'
  if (sh(script: 'exit -1', returnStatus: true) != 0) {
    unstable 'Optional tests failed…do not propagate failure'
  }
}
 
                                                            

stuartr@ea.com (JIRA)

unread,

Apr 10, 2019, 3:42:06 PM4/10/19

to jenkinsc...@googlegroups.com

Stuart Rowe commented on

Jesse Glick is unstable a step now?

stuartr@ea.com (JIRA)

unread,

Apr 10, 2019, 3:44:06 PM4/10/19

to jenkinsc...@googlegroups.com

Stuart Rowe edited a comment on

[~jglick] is {{unstable}} a step now? I thought it was only a condition for {{post}} in declarative pipelines.

jglick@cloudbees.com (JIRA)

unread,

Apr 10, 2019, 4:59:05 PM4/10/19

to jenkinsc...@googlegroups.com

Jesse Glick commented on

No, sorry for confusion. I was just sketching an edit to the original example by Kevin Phillips to not rely on a try-catch block, which would be undesirable in this context as it would catch not just nonzero exit status from a script but all sorts of other errors and even build interrupts and timeouts.

Saad.Azam@magna.com (JIRA)

unread,

Apr 12, 2019, 12:21:20 PM4/12/19

to jenkinsc...@googlegroups.com

Saad Azam updated an issue

Jenkins /

Change By:	Saad Azam
Attachment:	image-2019-04-12-18-20-27-978.png

Saad.Azam@magna.com (JIRA)

unread,

Apr 12, 2019, 12:22:04 PM4/12/19

to jenkinsc...@googlegroups.com

Saad Azam commented on

Hey Guys, I am trying a very simple code with no parallel stage in there yet I can't see the blue motion plugin indicating the failed stage correctly, see my example below:

 
                                                                pipeline {
    agent {label "NIGHTLY"}
    stages {
        stage ('test 1') {
            steps {
                sh 'exit 0'
            }
        }
        stage ('test 2') {
            steps {
                script {
                    catchError {
                        sh 'exit -1'
                    } 
                }
            }
        }
        stage ('test 3') {
            steps {
                sh 'exit 0'
            }
        }
    }
}
 
                                                            

Saad.Azam@magna.com (JIRA)

unread,

Apr 12, 2019, 12:23:18 PM4/12/19

to jenkinsc...@googlegroups.com

Saad Azam edited a comment on

Hey Guys, I am trying a very simple code with no parallel stage in there yet I can't see the blue motion plugin indicating the failed stage correctly, see my example below:
{code:java}

pipeline {
    agent {label "NIGHTLY"}
    stages {
        stage ('test 1') {
            steps {
                sh 'exit 0'
            }
        }
        stage ('test 2') {
            steps {
                script {
                    catchError {
                     sh 'exit -1'
                    }
                }
            }
        }
        stage ('test 3') {
            steps {
                sh 'exit 0'
            }
        }
    }
}

{code}
!image-2019-04-12-18-20-27-978.png|width=997,height=400!

Saad.Azam@magna.com (JIRA)

unread,

Apr 15, 2019, 5:00:24 AM4/15/19

to jenkinsc...@googlegroups.com

Saad Azam updated an issue

Jenkins /

Comment:
Change By:	Saad Azam

I am trying a very simple code with no parallel stage in there yet I can't see the blue motion plugin indicating the failed stage correctly, see my example below:
{code:java}
pipeline {
    agent {label "NIGHTLY"}
    stages {
        stage ('test 1') {
            steps {
                sh 'exit 0'
            }
        }
        stage ('test 2') {
            steps {
                script {
                    catchError {
                     sh 'exit -1'
                    }
                }
            }
        }
        stage ('test 3') {
            steps {
                sh 'exit 0'
            }
        }
    }
}
{code}
!image-2019-04-12-18-20-27-978.png|width=997,height=400!

Saad.Azam@magna.com (JIRA)

unread,

Apr 15, 2019, 7:15:05 AM4/15/19

to jenkinsc...@googlegroups.com

Saad Azam commented on

https://issues.jenkins-ci.org/browse/JENKINS-45579?focusedCommentId=307227&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-307227

Another thing is that the behavior described earlier about the fact that build stage shows the correct node rendering when not using parallel (link to the comment below) does not hold true for a declarative pipeline.

nofarb@gmail.com (JIRA)

unread,

Apr 24, 2019, 2:00:37 PM4/24/19

to jenkinsc...@googlegroups.com

Nofar Bluestein commented on

Hello,

I'm a Product Manager at CloudBees and we're currently working on a design for this request, and I would love to get your feedback on the suggested solution:

We were thinking of expanding the functionality of "catchError" block as follows:

+Current default behavio+r (will be maintained for backward compatibility) when an error is caught:

Step result is failed (though execution of the pipeline continues)
Stage result is success
Build result is failed

Suggested changes:

Add ability to set arguments to determine the desired results upon a caught error:

Stage result : success/failure (default: success)
Build result: success/failure (default: failure)

In addition, a very common use case is the ability to set a warning - mark the build and a stage in it as one that warrants attention without failing the build. To support that, we're considering adding a new block called "warnError", which will behaves as follows:

If an error is caught:
Step result is failed
Stage result is set to unstable
Build result is set to unstable

(we're also fixing the issue where if a build becomes unstable it's hard to pinpoint which stage caused the build to become unstable )

Thank you,

Nofar Bluestein,

Product Manager, CloudBees

nofarb@gmail.com (JIRA)

unread,

Apr 24, 2019, 2:01:07 PM4/24/19

to jenkinsc...@googlegroups.com

Nofar Bluestein edited a comment on

Hello,

I'm a Product Manager at CloudBees and we're currently working on a design for this request, and I would love to get your feedback on the suggested solution:

We were thinking of expanding the functionality of "[*catchError*| [https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/ #catcherror-catch-error-and-set-build-result]]" block as follows:

+ Current default behavio+r behavior (will be maintained for backward compatibility) when an error is caught:
* Step result is failed (though execution of the pipeline continues)
* Stage result is success
* Build result is failed

+Suggested changes:+

Add ability to set arguments to determine the desired results upon a caught error:

* Stage result : success/failure (default: success)
* Build result: success/failure (default: failure)

In addition, a very common use case is the ability to set a warning - mark the build and a stage in it as one that warrants attention without failing the build. To support that, we're considering adding a new block called "*warnError*", which will behaves as follows:
* If an error is caught:
* * Step result is failed
* * Stage result is set to unstable
* * Build result is set to unstable

(we're also fixing the [ issue |https://issues.jenkins-ci.org/browse/JENKINS-39203] where if a build becomes unstable it's hard to pinpoint which stage caused the build to become unstable )

Thank you,

Nofar Bluestein,

Product Manager, CloudBees

nofarb@gmail.com (JIRA)

unread,

Apr 24, 2019, 2:03:07 PM4/24/19

to jenkinsc...@googlegroups.com

Nofar Bluestein edited a comment on

Hello,

I'm a Product Manager at CloudBees and we're currently working on a design for this request, and I would love to get your feedback on the suggested solution:

We were thinking of expanding the functionality of "[*catchError*|#catcherror-catch-error-and-set-build-result]]" block as follows:

Current default behavior (will be maintained for backward compatibility) when an error is caught:

* Step result is failed (though execution of the pipeline continues)
* Stage result is success
* Build result is failed

+Suggested changes:+

Add ability to set arguments to determine the desired results upon a caught error:
* Stage result : success/failure (default: success)
* Build result: success/failure (default: failure)

In addition, a very common use case is the ability to set a warning - mark the build and a stage in it as one that warrants attention without failing the build. To support that, we're considering adding a new block called "*warnError*", which will behaves behave as follows:

* If an error is caught:
** Step result is failed

** Stage result is set to unstable
** Build result is set to unstable

(we're also fixing the issue where if a build becomes unstable it's hard to pinpoint which stage caused the build to become unstable )

Thank you,

Nofar Bluestein,

Product Manager, CloudBees

brian.villanueva@nice.com (JIRA)

unread,

Apr 24, 2019, 4:04:05 PM4/24/19

to jenkinsc...@googlegroups.com

Brian Villanueva commented on

Nofar Bluestein - Sounds great. I'm not too concerned about syntax decisions, as long as the basic issues are addressed. This sounds like a very reasonable solution. Glad the issue is getting some attention!

Saad.Azam@magna.com (JIRA)

unread,

Apr 25, 2019, 7:29:05 AM4/25/19

to jenkinsc...@googlegroups.com

Saad Azam commented on

Nofar Bluestein - Many thanks for the response. The changes you suggested are exactly what I am looking forward to have in declarative pipeline. In case it is not too much of an ask for you, it would be nice to get a rough estimate about when are the suggested changes going to be rolled out.

Nancy.Robertson@ca.ibm.com (JIRA)

unread,

Apr 25, 2019, 9:46:05 AM4/25/19

to jenkinsc...@googlegroups.com

Nancy Robertson commented on

Nofar Bluestein - Many thanks for looking into this. Your proposal sounds good. I am particularly interested in the handling of the unstable condition. Our pipelines are mostly scripted, and we have been using the error() function to mark failed stages, but it would help to be able to mark stages as unstable and keep going. Does your current plan include the addition of an unstable() step?

nofarb@gmail.com (JIRA)

unread,

Apr 26, 2019, 3:14:43 PM4/26/19

to jenkinsc...@googlegroups.com

Nofar Bluestein commented on

Thank you for the feedback!

Saad Azam I cannot commit to an ETA at the moment, but I can tell you it's a high priority for us, and we intend to start working on it in the next sprint.

Nancy Robertson in scripted pipelines the following should work:

`warnError { error() }` would have the same result

nofarb@gmail.com (JIRA)

unread,

Apr 26, 2019, 3:15:03 PM4/26/19

to jenkinsc...@googlegroups.com

Nofar Bluestein edited a comment on

Thank you for the feedback!

[~saad_azam] I cannot commit to an ETA at the moment, but I can tell you it's a high priority for us, and we intend to start working on it in the next sprint . I will provide additional update soon.

[~nancyrobertson2005] in scripted pipelines the following should work:

`warnError \{ error() }` would have the same result

nofarb@gmail.com (JIRA)

unread,

Apr 26, 2019, 5:15:05 PM4/26/19

to jenkinsc...@googlegroups.com

Nofar Bluestein edited a comment on

Thank you for the feedback!

[~saad_azam] I cannot commit to an ETA at the moment, but I can tell you it's a high priority for us,. I will provide additional update soon.

[~nancyrobertson2005] in scripted pipelines the following should work:

`warnError \{ error() }` would have the same result , but I will consider adding 'unstable' step so it's more elegant and consistent with the 'error' step

shanidar1@gmail.com (JIRA)

unread,

Apr 28, 2019, 6:26:05 AM4/28/19

to jenkinsc...@googlegroups.com

Shani Dar commented on

Nofar Bluestein Thanks for the update! looking forward to use the stage status solution.

dnusbaum@cloudbees.com (JIRA)

unread,

May 15, 2019, 3:16:05 PM5/15/19

to jenkinsc...@googlegroups.com

Devin Nusbaum commented on

Pipeline: Basic Steps Plugin version 2.16 added the new warnError and unstable steps and changes to catchError that Nofar Bluestein mentioned, see the 2.16 release notes for details on the specifics. See this comment on JENKINS-39203 for additional information on related issues. You need to update to Pipeline: Graph Analysis 1.10 for these steps to be visualized correctly by Blue Ocean.

Should we close this issue and open more specific issues related to the request for a step to set the build result to FAILURE but continue execution and a step to set the build result to ABORTED and abort the build, or handle them as part of this ticket?

dnusbaum@cloudbees.com (JIRA)

unread,

May 15, 2019, 3:20:05 PM5/15/19

to jenkinsc...@googlegroups.com

Devin Nusbaum updated an issue

Jenkins /

Change By:	Devin Nusbaum
Released As:	Pipeline: Basic Steps 2.16

remy.garrigue+jenkins@gmail.com (JIRA)

unread,

May 17, 2019, 7:26:21 AM5/17/19

to jenkinsc...@googlegroups.com

RG commented on

Hi. Would you mind adding an example in https://github.com/jenkinsci/pipeline-examples ? I'm not exactly an expert and coming up with the right syntax assembling bit of code & release note is quite hard.

Saad.Azam@magna.com (JIRA)

unread,

May 21, 2019, 4:00:52 AM5/21/19

to jenkinsc...@googlegroups.com

Saad Azam commented on

Devin Nusbaum I have tried the latest update with newly added 'unstable' step as well as updated 'catchError'. I am now able to setup and visualize individual stage status independently. Many thanks.

dnusbaum@cloudbees.com (JIRA)

unread,

May 23, 2019, 10:57:05 AM5/23/19

to jenkinsc...@googlegroups.com

Devin Nusbaum commented on

RG You can use the "Pipeline Syntax" link in the sidebar of a Pipeline job in Jenkins to get a visual interface that will show you the options provided by catchError, warnError, and unstable and will allow you to generate the actual syntax that would go in a Pipeline given the options you specify.

I will look into adding something to the examples repo.

brian.murrell@intel.com (JIRA)

unread,

Jun 3, 2019, 10:20:39 AM6/3/19

to jenkinsc...@googlegroups.com

Brian J Murrell commented on

I used the Pipeline Syntax snippet generator to generate me a catchError step and it produced:

 
                                                                catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
 // some block
}

which then chokes Jenkins with:

 
                                                                WorkflowScript: 147: Expecting "class hudson.model.Result" for parameter "buildResult" but got "SUCCESS" of type class java.lang.String instead @ line 147, column 49.
         catchError(buildResult: 'SUCCESS',
                                 ^

dnusbaum@cloudbees.com (JIRA)

unread,

Jun 3, 2019, 10:22:05 AM6/3/19

to jenkinsc...@googlegroups.com

Devin Nusbaum commented on

Brian J Murrell Yes, turns out that Declarative doesn't like the parameter types for `catchError`. See JENKINS-57537 for more information, I am working on a fix that should be ready soon.

brian.murrell@intel.com (JIRA)

unread,

Jun 3, 2019, 10:23:06 AM6/3/19

to jenkinsc...@googlegroups.com

Brian J Murrell edited a comment on

I used the Pipeline Syntax snippet generator to generate me a {{catchError}} step and it produced:

{noformat}

catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
// some block
}

{noformat}

which then chokes Jenkins with:

{noformat}

WorkflowScript: 147: Expecting "class hudson.model.Result" for parameter "buildResult" but got "SUCCESS" of type class java.lang.String instead @ line 147, column 49.
catchError(buildResult: 'SUCCESS',
^

{noformat}

Removing the single quotes surrounding the {{SUCCESS}} and {{FAILURE}} values seems to at least keep the linter happy and the pipeline at least runs. Still waiting to see if these new values have the desired effect though. :-)

brian.murrell@intel.com (JIRA)

unread,

Jun 3, 2019, 10:46:05 AM6/3/19

to jenkinsc...@googlegroups.com

Brian J Murrell commented on

Devin Nusbaum Oh, this is a pity. catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') was going to solve exactly the problem I newly have on hand today, which is how to let a step fail, mark it's stage as failed but not fail the overall job.

I'm really loathed to make the step and stage look like it succeeded (because it will mask failures that need investigating) just so that the rest of the stages get run and overall job passes.

brian.murrell@intel.com (JIRA)

unread,

Jun 3, 2019, 2:13:05 PM6/3/19

to jenkinsc...@googlegroups.com

Brian J Murrell commented on

Devin Nusbaum New issue filed about catchError(), and the post processing block, FWIW.

dnusbaum@cloudbees.com (JIRA)

unread,

Jul 29, 2019, 1:36:07 PM7/29/19

to jenkinsc...@googlegroups.com

Devin Nusbaum commented on

The original example in the description of this ticket was fixed as part of ~~JENKINS-39203~~ with the new warnError and unstable steps and changes to the catchError step, so I am going to close this issue See https://jenkins.io/blog/2019/07/05/jenkins-pipeline-stage-result-visualization-improvements/ and this earlier comment for details. if you have a request for a step that is related to the general title of the ticket but is not covered by the changes I mentioned, please file a new ticket along the lines of JENKINS-27092.

dnusbaum@cloudbees.com (JIRA)

unread,

Jul 29, 2019, 1:37:13 PM7/29/19

to jenkinsc...@googlegroups.com

Devin Nusbaum resolved as Fixed

Jenkins /

Change By:	Devin Nusbaum
Status:	Reopened Resolved
Assignee:	Devin Nusbaum
Resolution:	Fixed