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

Run parameter behaves differently between input step and job parameter

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When --JENKINS-27295-- was implemented there was a specific serialisation check in place that blocked RunParamaterValue from adding to the params array that provides access to the real object, rather than a string representation of it.

      On some recent testing if an input step is used to request a build be selected:

       

        wah = input message: '', parameters: [run(description: '', filter: 'SUCCESSFUL', name: '', projectName: 'cme/example_02_artefact/master')]
      

      Then the object returned is the Run object that you can then do getDisplayName or getDescription on ...

       

      If instead of an input step a build parameter is used: 

      properties([parameters([run(description: 'Select the version of the artifact to deploy', filter: 'SUCCESSFUL', name: 'deploy_artifact', projectName: 'cme/example_02_artefact/master')])])
      

      Then the variable (direct or through env.foo) is just the $BUILD_URL of the build selected as a string, and there's no Run object on params to access more detail about that build.

       

      These should be made consistent so that either the input step only returns the string job_url to match the build params, or the Run object itself should be accessible when using a build parameter ... naturally I'd prefer the latter as it's way more flexible.

       

        Attachments

          Activity

          Hide
          hogarthj James Hogarth added a comment -

          Actually having bumped into a bunch of serialization issues with the object from the input step ... I'm reversing my preference.

          It'd be much better for input to return the same as the build parameter ... the full url to the build (or the runId) which of course is a pure string and has no serialization issues.

          The Run object is otherwise irritatingly painful to deal with due to CPS concerns.

          Show
          hogarthj James Hogarth added a comment - Actually having bumped into a bunch of serialization issues with the object from the input step ... I'm reversing my preference. It'd be much better for input to return the same as the build parameter ... the full url to the build (or the runId) which of course is a pure string and has no serialization issues. The Run object is otherwise irritatingly painful to deal with due to CPS concerns.

            People

            • Assignee:
              Unassigned
              Reporter:
              hogarthj James Hogarth
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: