Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68288

Object context in BuildCondition.meetsCondition is sometimes a Stage instance, which is not recognized by BuildCondition.getCombinedResult

      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.

      This inconsistency came from PR #330 for JENKINS-57826.

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

          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.

          Kalle Niemitalo added a 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.

            Unassigned Unassigned
            kon Kalle Niemitalo
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: