[JENKINS-26093] Better support for build step parameters

[jglick]

Part of JENKINS-26093 so far.

@reviewbybees

[jglick]

@reviewbybees should be ready for review.

[stephenc]

👍 from me but did you ever resolve the $class fight with @kohsuke

[tfennelly]

👍

[jglick]

Just occurred to me that this will not handle relative paths, need to fix that.

[jglick]

Build 953 from 495edb4 was stable (the PR builder is having trouble noting that here), so again @reviewbybees.

[stephenc]

I'm still 👍 but I think we want @kohsuke to review the $class stuff as it seems against his vision

[tfennelly]

👍

Note sure I totally understand it though (StaplerReferer etc`).

[jglick]

Regarding $class here: there is a ParameterValue.getValue which @kohsuke added recently (without any actual uses, AFAICT); JENKINS-26093 notes that an alternate approach under consideration was the creation of ParameterDefinition.createValue(Object), which would presumably let you specify the parameters as a Map<String,Object>. (At runtime the definitions would need to be looked up in the downstream project so you would know whether a String value was meant to become a StringParameterValue, PasswordParameterValue, etc.) If such an API were added and WF were to depend on the appropriate core version, this would still be an option, presumably with a new @DataBoundSetter taking such a map, and some more hacking around in Jelly and Snippetizer to make the Snippet Generator produce that.

Here (in 72860e9, the non-UI part of the PR) I am going with a more conservative change. parameters still accepts a list of actual ParameterValue objects, but the preferred mode is to use the $class data binding style, which (a) avoids the need to import Jenkins model classes, (b) does not trigger sandbox violations.

[jglick]

StaplerReferer is needed because StaplerRequest.findAncestor, used here to look up the WorkflowJob being configured so that a relative job path can be interpreted correctly, does not work when called from a dynamically-injected form fragment.