-
Bug
-
Resolution: Unresolved
-
Minor
When ---- 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.JENKINS-27295
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.
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.