[JIRA] (JENKINS-57826) catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE

1 view
Skip to first unread message

brian.murrell@intel.com (JIRA)

unread,
Jun 3, 2019, 2:11:02 PM6/3/19
to jenkinsc...@googlegroups.com
Brian J Murrell created an issue
 
Jenkins / Bug JENKINS-57826
catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
Issue Type: Bug Bug
Assignee: Unassigned
Components: pipeline
Created: 2019-06-03 18:10
Environment: Jenkins: 2.164.3
Pipeline: Basic Steps: 2.16
Priority: Critical Critical
Reporter: Brian J Murrell

If I have a stage with a step in it:

                         ...
                         catchError(buildResult: hudson.model.Result.SUCCESS,
                                   message: 'RPM build failed, but allowing job to continue',
                                   stageResult: hudson.model.Result.FAILURE) {
                            sh label: env.STAGE_NAME,
                               script: 'exit 2'
                        }

With a post block for the stage:

                    post {
                        always {
                            archiveArtifacts artifacts: 'artifacts/**'
                        }
                        success {
                            println "${env.STAGE_NAME}: SUCCESS"
                        }
                        unstable {
                            println "${env.STAGE_NAME}: UNSTABLE"
                        }
                        failure {
                            println "${env.STAGE_NAME}: FAILED"
                        }
                    }

 I actually get the:

My Test Stage: SUCCESS

telling me that the stage was a SUCCESS, not a FAILURE like the:

catchError(..., stageResult: hudson.model.Result.FAILURE) is supposed to be making it.

In both the stage view and the Blue Ocean view, it does show as a failed stage. The post processing block just doesn't see it that way.

As an aside, is there a variable set for the stage that I could use in my println above so that I could just do a single println in the always block rather than having to repeat it through the success, unstable and failure blocks?
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

dnusbaum@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:26:02 PM6/3/19
to jenkinsc...@googlegroups.com
Devin Nusbaum commented on Bug JENKINS-57826
 
Re: catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE

Yeah, we need to change how post conditions are handed in Declarative to make this work if you are using catchError with a buildResult and stageResult that do not match. My first thought would be to add a new overload of BuildCondition.getCombinedResult that takes two new FlowNode parameters, one for the start of the stage or parallel block the post is associated with, and one for the end, and then use them to call StatusAndTiming.findWarningBetween (maybe move that method to workflow-api?), and then update all of the callers in Declarative to use the new version of BuildCondition.getCombinedResult. CC Andrew Bayer.

dnusbaum@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:27:02 PM6/3/19
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
 
Change By: Devin Nusbaum
Labels: pipeline

dnusbaum@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:27:02 PM6/3/19
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
Change By: Devin Nusbaum
Component/s: pipeline-model-definition-plugin
Component/s: pipeline

dnusbaum@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:30:02 PM6/3/19
to jenkinsc...@googlegroups.com
 
Re: catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE

BTW as a temporary workaround, if you are ok with marking the build and stage result as unstable, you can just use warnError instead. Also note that my proposed fix for JENKINS-57537 is going to break the way you are using buildResult: hudson.model.Result.SUCCESS, so I wouldn't go too much further with custom result for catchError in Declarative until that is fixed and you can go back to writing buildResult: 'SUCCESS'.

brian.murrell@intel.com (JIRA)

unread,
Jun 3, 2019, 2:38:02 PM6/3/19
to jenkinsc...@googlegroups.com

Isn't the post for a stage supposed to be acting on the result of that stage?  I'm wondering how/why any kind of combined result or overall job result is even a factor in assessing which post blocks to run for the stage when catchError is successfully setting the result for that stage.

as a temporary workaround, if you are ok with marking the build and stage result as unstable

That won't work unfortunately. UNSTABLE in our workflow specifically prevents landing since it's the result of having failed junit test results. So we can't live with marking the overall build result as UNSTABLE when only stages that are not supposed to block landing fail.

break the way you are using buildResult: hudson.model.Result.SUCCESS

That's fine.  I am using it completely understanding that it's only temporary while I wait for JENKINS-57537 to be available.

dnusbaum@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:54:02 PM6/3/19
to jenkinsc...@googlegroups.com

Isn't the post for a stage supposed to be acting on the result of that stage?  I'm wondering how/why any kind of combined result or overall job result is even a factor in assessing which post blocks to run for the stage when catchError is successfully setting the result for that stage.

Before this change there was no such thing as a stage result (and technically with recent changes there still isn't, we just have step results that are aggregated at the stage level). There was no way to make existing code that deals with results use the new step result API transparently, so we still need to be able to handle anything setting the overall build result or throwing an exception (if the current build result is UNSTABLE, but the stage threw an exception (which doesn't change the build result directly), we only want to run the FAILURE post condition, not the UNSTABLE one, hence BuildCondition.combineResults), unless we make post blocks only work for catchError, unstable, and warnError, and the few other steps that are using the new API, but that would break many (maybe most?) existing use cases, especially around things like currentBuild.result, which is and always will be oblivious to the new step-level API.

andrew.bayer@gmail.com (JIRA)

unread,
Jun 3, 2019, 2:56:02 PM6/3/19
to jenkinsc...@googlegroups.com

Yeah, we're going to need to add per-stage status support to Declarative post for sure.

brian.murrell@intel.com (JIRA)

unread,
Jun 4, 2019, 8:42:01 AM6/4/19
to jenkinsc...@googlegroups.com

(At the risk of preaching to the choir, but also not wanting to leave it unsaid) regardless of how it's achieved, having the post stages react and act according to the stage status set by catchError (and friends) is paramount because (again, to be obvious, but explicit,) having the post stages not act according to status of the stage I think is just going to add even more confusion to this already confusing big can of worms.

Any estimate on the size/effort of fixing the post processing, since I think for many cases, the (excellent!, BTW) advancements made in the Pipeline Basic Steps plugin really get nullified by not being able to post based on the stage status that can now be set.  I wouldn't imagine there are very many pipelines that don't do at least a minimal amount of post based on the result of the stage.  But maybe I am wrong about that guesstimate.

andrew.bayer@gmail.com (JIRA)

unread,
Jun 5, 2019, 10:01:02 AM6/5/19
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Bug JENKINS-57826
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Jun 5, 2019, 10:01:03 AM6/5/19
to jenkinsc...@googlegroups.com
Andrew Bayer assigned an issue to Andrew Bayer
 
Change By: Andrew Bayer
Assignee: Andrew Bayer

andrew.bayer@gmail.com (JIRA)

unread,
Jun 5, 2019, 10:02:02 AM6/5/19
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Progress Review

andrew.bayer@gmail.com (JIRA)

unread,
Jun 5, 2019, 10:03:02 AM6/5/19
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Jun 7, 2019, 12:59:02 PM6/7/19
to jenkinsc...@googlegroups.com
 

Woo, merged - it'll be in 1.3.9, which I should release soon.
Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:19:03 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages