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.)

Steps to reproduce the problem:

1. Create and configure a Workflow "upstreamWorkflow"
   • This build is parameterized
     • String Parameter
       • Name: Product
   • Workflow
     • Definition: Groovy CPS DSL
     • Script:

       node {
           writeFile text: "${Product}", file: 'artifact.txt'
           archive includes: '**/*'
       }
       

2. Build upstreamWorkflow with "Product=development"
3. Build upstreamWorkflow with "Product=production"
4. Create and configure a Freestyle project "downstream"
   • This build is parameterized
     • String Parameter
       • Name: ProductToCopy
   • Add a build strep: Copyartifacts from another project
     • Project name: upstreamWorkflow
     • Which build: Last successful build
     • Parameter filters: Product=${ProductToCopy}
5. Build downstream with "ProductToCopy=development"

Result:

• Build fails

Notes:

• It succeeds without Parameter filters
• It success if the upstream is a free style project.

attached build.xml of upstreamWorkflow.

What AbstractBuild#getEnvironments(TaskListener) does additional to what Run#getEnvironments(TaskListener) does:

• defines WORKSPACE
• defines variables from SCM (like GIT_BRANCH, GIT_COMMIT in git plugin)
• defines variables from RunListenre s.
• defines variables from NodeProperty s.
• defines variables from EnvironmentContributingAction s.
  • ParametesAction is a EnvironmentContributingAction , and defines build parameters.

I know workflow cannot resolve this so soon as EnvironmentContributingAction works only for AbstractBuild and I'll work for the fix @jglick mentioned.

At the same time, I know that it may not work for all cases like a user wants to filter builds with GIT_BRANCH (which is provided by SCM). And I think plugins often use Run#getEnvironment(TaskListener) to retrieve parameters and it may cause problems with workflow.
I expect the day Jenkins and workflow provide a complete alternate solution for this problem.

Is there a workaround to access custom job parameters from the groovy script?

Answering my own question - https://issues.jenkins-ci.org/browse/JENKINS-26194