Status: Open (View Workflow)
Pipeline: Declarative 1.9.3
If BuildCondition.getCombinedResult is called in relation to a stage, then its Object context parameter can be either a Stage instance or the name of the stage as a String. BuildCondition.getCombinedResult however recognizes only the String type and not the Stage type. If a Stage instance is passed in, then BuildCondition.getCombinedResult does not search for a WarningAction in the stage, and might compute an incorrect Result.
I found this while looking at the source code for the sake of
JENKINS-68281. I have not reproduced the problem in practice.
- Stage instance: ModelInterpreter.executeSingleStage calls Root.hasSatisfiedConditions, which calls AbstractBuildConditionResponder.satisfiedConditions, which calls BuildCondition.meetsCondition(Object runWrapperObj, Object context, Throwable error), which calls BuildCondition.meetsCondition(WorkflowRun r, Object context, Throwable error), which is overridden by Success.meetsCondition, which calls BuildCondition.combineResults, which calls BuildCondition.getCombinedResult, which does not recognize the Stage type.
- Name of the stage as a String: ModelInterpreter.runPostConditions calls BuildCondition.getCombinedResult, which recognizes the String type.
This inconsistency came from PR #330 for
- relates to
JENKINS-57801 Execution of post stage block is based on pipeline status, not stage result which docs says it should
JENKINS-57826 catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
I unsuccessfully tried to reproduce the problem with this pipeline:
I expected that the first stage would set the stage result as UNSTABLE but the build result as SUCCESS, and the bug would cause BuildCondition.meetsCondition to consider only the build result and not the stage result. It would then return false, ModelInterpreter.runPostConditions would not be called, and "First post unstable" would not be output.
However, the log from this pipeline was:
Somehow, the currentBuild.result = 'SUCCESS' assignment did not seem to take effect.