-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
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 JENKINS-57826.
- relates to
-
JENKINS-57801 Execution of post stage block is based on pipeline status, not stage result which docs says it should
- Open
-
JENKINS-57826 catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
- Closed