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

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            kon Kalle Niemitalo created issue -

            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.

            kon 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.
            kon Kalle Niemitalo made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-57826 [ JENKINS-57826 ]
            kon Kalle Niemitalo made changes -
            Link This issue relates to JENKINS-57801 [ JENKINS-57801 ]

            People

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

              Dates

                Created:
                Updated: