[JENKINS-68288] Object context in BuildCondition.meetsCondition is sometimes a Stage instance, which is not recognized by BuildCondition.getCombinedResult

[jenkins-infra-bot]

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.

---

Originally reported by kon, imported from: Object context in BuildCondition.meetsCondition is sometimes a Stage instance, which is not recognized by BuildCondition.getCombinedResult

• status: Open
• priority: Minor
• component(s): pipeline-model-definition-plugin
• resolution: Unresolved
• votes: 0
• watchers: 1
• imported: 2025-12-06

Raw content of original issue

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.

• environment: Pipeline: Declarative 1.9.3

[jenkins-infra-bot]

kon:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  I unsuccessfully tried to reproduce the problem with this pipeline:
  
  pipeline {
      agent none
      stages {
          stage('First') {
              steps {
                  unstable 'Excuse'
                  script {
                      currentBuild.result = 'SUCCESS'
                      echo "got ${currentBuild.result}"
                  }
              }
              post {
                  unstable {
                      echo 'First post unstable'
                  }
              }
           }
          stage('Second') {
              steps {
                  echo 'Second main'
              }
              post {
                  success {
                      echo 'Second post success'
                  }
                  unstable {
                      echo 'Second post unstable'
                  }
              }
          }
      }
  }
  
  
  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:
  
  [Pipeline] Start of Pipeline
  [Pipeline] stage
  [Pipeline] { (First)
  [Pipeline] unstable
  WARNING: Excuse
  [Pipeline] script
  [Pipeline] {
  [Pipeline] echo
  got UNSTABLE
  [Pipeline] }
  [Pipeline] // script
  Post stage
  [Pipeline] echo
  First post unstable
  [Pipeline] }
  [Pipeline] // stage
  [Pipeline] stage
  [Pipeline] { (Second)
  [Pipeline] echo
  Second main
  Post stage
  [Pipeline] echo
  Second post unstable
  [Pipeline] }
  [Pipeline] // stage
  [Pipeline] End of Pipeline
  Finished: UNSTABLE
  
  
  Somehow, the currentBuild.result = 'SUCCESS' assignment did not seem to take effect.
  

I unsuccessfully tried to reproduce the problem with this pipeline:

pipeline {
    agent none
    stages {
stage('First') {
    steps {
unstable 'Excuse'
script {
    currentBuild.result = 'SUCCESS'
    echo "got ${currentBuild.result}"
}
    }
    post {
unstable {
    echo 'First post unstable'
}
    }
 }
stage('Second') {
    steps {
echo 'Second main'
    }
    post {
success {
    echo 'Second post success'
}
unstable {
    echo 'Second post unstable'
}
    }
}
    }
}

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:

[Pipeline] Start of Pipeline
[Pipeline] stage
[Pipeline] { (First)
[Pipeline] unstable
WARNING: Excuse
[Pipeline] script
[Pipeline] {
[Pipeline] echo
got UNSTABLE
[Pipeline] }
[Pipeline] // script
Post stage
[Pipeline] echo
First post unstable
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Second)
[Pipeline] echo
Second main
Post stage
[Pipeline] echo
Second post unstable
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: UNSTABLE

Somehow, the currentBuild.result = 'SUCCESS' assignment did not seem to take effect.