|
||||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The problem is in ParametersBuildFilter. (Why this is a filter as opposed to just a BuildSelector, I have no idea. Weird design.) It uses Run.getEnvironment(TaskListener), which does something with parameters in an AbstractBuild because ParametersAction happens to be an EnvironmentContributingAction.
A WorkflowRun does not override getEnvironment, since it has nothing special to add, and parameters in a workflow are passed as Groovy variables, not environment variables. (Anyway EnvironmentContributingAction is currently limited to use on AbstractBuild.) So that trick does not work.
Anyway there is no apparent reason why ParametersBuildFilter needs to use getEnvironment, which is a very roundabout way of looking for parameters. It can just look for ParametersAction and check them directly.
(Relying on StringParameterValue.equals would be intuitive but is not quite right, since the current code in ParametersBuildFilter assumes that it can match against a non-string ParameterValue whose textual expansion is the expected string. So you would need to call ParameterValue.buildEnvironment. Basically what ParametersAction.buildEnvVars does, without the gratuitous restriction to AbstractBuild.)