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

Job with Extensible Groovy script does NOT get latest value when triggered by another job

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have 2 Jenkins jobs, Job1 and Job2, and Job1 triggers Job2 via this pipeline DSL

      node('someNode') {
       stage('Call Job2') {
         build job: 'Job2',
               parameters: [
                 new StringParameterValue('ExtensibleChoiceParam',
                                          'TARGET_VERSION')
               ],
               wait: false
       }
      }

       
      Job2 has this Groovy script as its Extensible Choice Parameter for variable TARGET_VALUE, which provides a list of ALL successful builds for Job1

      // code placeholder
      import hudson.model.*
       
      BUILD_JOB_NAME = "Job1"
       
      def getBuildJob() {
          def buildJob = null
          Hudson.instance.getAllItems(Job.class).each {
              if (it.fullName == BUILD_JOB_NAME) {
                  buildJob = it
              }
          }
          return buildJob
      }
       
      List<String> getAllBuildNumbers(Job job) {
              List<String> buildNumbers = []
              (job.getBuilds()).each {
                  def status = it.getBuildStatusSummary().message
                  if (status.contains("stable") || status.contains("normal")) {
                      buildNumbers.add(it.displayName)
                  }
              }
              return buildNumbers
      }
       
      Job buildJob = getBuildJob()
      List<String> buildNumbers = null
      if (buildJob) {
        buildNumbers = getAllBuildNumbers(buildJob)
      }
      return buildNumbers
      

      Job2 does nothing but prints TARGET_VERSION, so it just does this

      node('someNode') {
        stage('Print TARGET_VERSION') {
          println "TARGET_VERSION: $TARGET_VERSION"
        }
      }

      If Job1 has the following build history for example,

      Build#    Status
      $4        Success
      #3        Fail
      #2        Success
      #1        Fail

       
      If I click on Job2's Build with parameters link, I get the correct list, that is, as shown below, so I know the script is correct.

      #4
      #2
      

      When Job1 triggers Job2 (per Job1's pipeline DSL above), I expect Job2 to print #4, Job1's latest successful build. However, it prints out #2, the previous successful build. Why?

        Attachments

          Activity

          Hide
          ikedam ikedam added a comment -
          Show
          ikedam ikedam added a comment - Because the build of Job1 is still running at that time. I believe getBuildStatusSummary() returns “?” https://github.com/jenkinsci/jenkins/blob/jenkins-2.164.3/core/src/main/java/hudson/model/Run.java#L2151 https://github.com/jenkinsci/jenkins/blob/jenkins-2.164.3/core/src/main/resources/hudson/model/Messages.properties#L246 And I recommend you not to use getBuildStatusSummary() as its output may be localized and changes for languages. I could not get what you wanted to do with passing StringParameterValue. I believe it does nothing.
          Hide
          ikedam ikedam added a comment -

          I failed to change the assignee.
          Please see the previous comment.

          Show
          ikedam ikedam added a comment - I failed to change the assignee. Please see the previous comment.
          Hide
          zillag Chris Fouts added a comment - - edited

          But Job1 has already finished running by the time Job2 runs because the wait parameter in the build() call is set to false?

          Show
          zillag Chris Fouts added a comment - - edited But Job1 has already finished running by the time Job2 runs because the wait  parameter in the build() call is set to false ?
          Hide
          ikedam ikedam added a comment -

          Chris Fouts Because the extensible-choice runs when a build is scheduled, not when starts.
          It has nothing to do with the `wait` parameter.

          Here is an issue tracker, not your support center nor stackoverflow.
          Please don't reopen closed ticket without any concrete evidences, like log outputs. I believe you can verify what happen easily with removing the `if` statement.

          Show
          ikedam ikedam added a comment - Chris Fouts Because the extensible-choice runs when a build is scheduled, not when starts. It has nothing to do with the `wait` parameter. Here is an issue tracker, not your support center nor stackoverflow. Please don't reopen closed ticket without any concrete evidences, like log outputs. I believe you can verify what happen easily with removing the `if` statement.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            zillag Chris Fouts
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: