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

parameter of type run not added to params

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      parameters of type run are not accessible by params. They are exposed as env:

      Jenkinsfile
      pipeline {
          agent none
      
          parameters {
              string(name:'stringParam', defaultValue: null)
              run(name: 'runParam', filter: 'ALL', projectName: 'some-other-job')
          }
          
          stages {
              stage('test') {
                  steps {
                      echo "params.stringParam: ${params.stringParam}"
                      echo "params.runParam: ${params.runParam}"
                      echo "env.runParam: ${env.runParam}"
                  }
              }
          }
      }
      

      Result:

      Started by user unknown or anonymous
      Running in Durability level: MAX_SURVIVABILITY
      [Pipeline] stage
      [Pipeline] { (test)
      [Pipeline] echo
      params.stringParam: xx
      [Pipeline] echo
      params.runParam: null
      [Pipeline] echo
      env.runParam: http://xxx/job/some-other-job/4/
      [Pipeline] }
      [Pipeline] // stage
      [Pipeline] End of Pipeline
      Finished: SUCCESS
      

        Attachments

          Activity

          Hide
          abayer Andrew Bayer added a comment -

          Regrettably, we can only include parameters in params if they're serializable - and a Run is not serializable. So we have to skip it and not add anything for that parameter. Sorry.

          Show
          abayer Andrew Bayer added a comment - Regrettably, we can only include parameters in params if they're serializable - and a Run is not serializable. So we have to skip it and not add anything for that parameter. Sorry.
          Hide
          akdor1154 Jarrad Whitaker added a comment -

          Erp that's a bit of a kuldge. Is it possible to just make a Run parameter serializable?

          Show
          akdor1154 Jarrad Whitaker added a comment - Erp that's a bit of a kuldge. Is it possible to just make a Run parameter serializable?
          Hide
          akdor1154 Jarrad Whitaker added a comment - - edited

          See bludgeon-level PR at https://github.com/jenkinsci/jenkins/pull/3578 .

          Can't find docs on how you go about making API changes (maybe that means you never do? eep), but as a sanity check, I cannot find any usages of `getValue()` on a `RunParameterValue` by using github search on the jenkinsci organization. (Searched for `RunParameterValue` and manually inspected usages. I guess it's still possible that someone could use ParameterValue.getValue instanceof Run...).

          Edit: also searched for "instanceof Run" "ParameterValue" with no relevant results.

          Is this approach worth pursuing?

          Show
          akdor1154 Jarrad Whitaker added a comment - - edited See bludgeon-level PR at https://github.com/jenkinsci/jenkins/pull/3578 . Can't find docs on how you go about making API changes (maybe that means you never do? eep), but as a sanity check, I cannot find any usages of `getValue()` on a `RunParameterValue` by using github search on the jenkinsci organization. (Searched for `RunParameterValue` and manually inspected usages. I guess it's still possible that someone could use ParameterValue.getValue instanceof Run...). Edit: also searched for "instanceof Run" "ParameterValue" with no relevant results. Is this approach worth pursuing?
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Re-pening since there is a PR to the core: https://github.com/jenkinsci/jenkins/pull/3578

          Show
          oleg_nenashev Oleg Nenashev added a comment - Re-pening since there is a PR to the core: https://github.com/jenkinsci/jenkins/pull/3578
          Hide
          reinholdfuereder Reinhold Füreder added a comment -

          Naive thought: Would it make sense to at least add the most important value, i.e. either (a) the value of env.runParam (pros: it contains everything; cons: it contains everything and must therefore be parsed) or (b) the value of env.runParam_NUMBER (pros: it only contains the unknown non-customizable – cf. display name – build ID and in addition with the jobname/project name that was a parameter to the run parameters step everything is known; cons: is there one? Maybe that the params.runParam is a build number might be a bit surprising; but IMHO less surprising as if the params.runParam is just null like now)

          => params.runParam = env.runParam_NUMBER

          pipelineJobName = 'some-other-job' // Like for run parameters
          buildNumber = params.runParam
          
              Job job = (Job) Jenkins.get().getItemByFullName(pipelineJobName, Job.class)
              if (!job) {
                throw new Exception("Failed to find pipeline job '${pipelineJobName}'")
              }
              Run run = job.getBuildByNumber(buildNumber)
              if (!run) {
                throw new Exception("There is no build with number '${buildNumber}' for pipeline job '${pipelineJobName}'")
              }
              // TODO: Use 'run'...
          

          I guess this would be also very easy to implement for someone like Oleg Nenashev or Andrew Bayer ^^ and also not really breaking backwards compatibility...

          Show
          reinholdfuereder Reinhold Füreder added a comment - Naive thought: Would it make sense to at least add the most important value, i.e. either (a) the value of env.runParam (pros: it contains everything; cons: it contains everything and must therefore be parsed) or (b) the value of env.runParam_NUMBER (pros: it only contains the unknown non-customizable – cf. display name – build ID and in addition with the jobname/project name that was a parameter to the run parameters step everything is known; cons: is there one? Maybe that the params.runParam is a build number might be a bit surprising; but IMHO less surprising as if the params.runParam is just null like now) => params.runParam = env.runParam_NUMBER pipelineJobName = 'some-other-job' // Like for run parameters buildNumber = params.runParam Job job = (Job) Jenkins.get().getItemByFullName(pipelineJobName, Job.class) if (!job) { throw new Exception( "Failed to find pipeline job '${pipelineJobName}' " ) } Run run = job.getBuildByNumber(buildNumber) if (!run) { throw new Exception( "There is no build with number '${buildNumber}' for pipeline job '${pipelineJobName}' " ) } // TODO: Use 'run' ... I guess this would be also very easy to implement for someone like Oleg Nenashev or Andrew Bayer ^^ and also not really breaking backwards compatibility...
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Sorry, I am snowed under the Jenkins UI/UX hackfest and my responses might be delayed.

           

          Show
          oleg_nenashev Oleg Nenashev added a comment - Sorry, I am snowed under the Jenkins UI/UX hackfest and my responses might be delayed.  

            People

            Assignee:
            oleg_nenashev Oleg Nenashev
            Reporter:
            scddev Dietmar Scheidl
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: