-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 1.598 on Linux
Workflow:Aggregator plugin 1.2
CopyArtifact plugin: 1.34
If I use the CopyArtifact plugin with a workflow step(), it correctly pulls the latest successful build's artifacts when pointed to a project of type Workflow.
However, if I specify parameters for that same project, it will always throw an AbortException saying no build with those parameters could be found, regardless of what I entered in.
If I change the CopyArtifact to point to a freestyle project, the parameters correctly work as intended, pulling in most recent build that had those parameters.
Since the CopyArtifact is behaving as it should, I'm assuming there's a flaw in how the Workflow plugin is exposing its build Parameters.
Sample code:
step ([$class: 'CopyArtifact', projectName: 'Test Run Composer', target: 'composer_run', parameters: "PRODUCT=test,BRANCH_NAME=$branch_name" ]);
- is related to
-
JENKINS-30357 CopyArtifact step fails when using ParameterizedBuildSelector class for selecting build
-
- Closed
-
-
JENKINS-32209 NodeLabel parameter not working inside workflow
-
- Closed
-
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.)