-
Bug
-
Resolution: Fixed
-
Critical
-
Jenkins: 2.164.3
Pipeline: Basic Steps: 2.16
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?
- relates to
-
JENKINS-45579 Step to set stage or parallel status
-
- Resolved
-
-
JENKINS-68288 Object context in BuildCondition.meetsCondition is sometimes a Stage instance, which is not recognized by BuildCondition.getCombinedResult
-
- Open
-
- links to
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 abayer.