Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26694

Workflow build Parameters are not exposed to CopyArtifact

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • copyartifact-plugin
    • 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"
            ]);
      

          [JENKINS-26694] Workflow build Parameters are not exposed to CopyArtifact

          Jesse Glick added a comment -

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

          Jesse Glick added a comment - 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 .)

          ikedam added a comment -

          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.

          ikedam added a comment - Steps to reproduce the problem: 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: '**/*' } Build upstreamWorkflow with "Product=development" Build upstreamWorkflow with "Product=production" 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} 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.

          ikedam added a comment -

          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.

          ikedam added a comment - 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?

          Bastian Echterhoelter added a comment - Is there a workaround to access custom job parameters from the groovy script?

          Bastian Echterhoelter added a comment - Answering my own question - https://issues.jenkins-ci.org/browse/JENKINS-26194

          Code changed in jenkins
          User: ikedam
          Path:
          src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
          http://jenkins-ci.org/commit/copyartifact-plugin/abd5a3067a3a0769115cd73716978545ff7892bc
          Log:
          JENKINS-26694 Added a test to reproduce JENKINS-26694.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java http://jenkins-ci.org/commit/copyartifact-plugin/abd5a3067a3a0769115cd73716978545ff7892bc Log: JENKINS-26694 Added a test to reproduce JENKINS-26694 .

          Code changed in jenkins
          User: ikedam
          Path:
          src/main/java/hudson/plugins/copyartifact/ParametersBuildFilter.java
          http://jenkins-ci.org/commit/copyartifact-plugin/53462816b1d9f3455a3422d89bc5d6feaff274f1
          Log:
          [FIXED JENKINS-26694] ParameterBuildFilter now works also for WorkflowRun.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/main/java/hudson/plugins/copyartifact/ParametersBuildFilter.java http://jenkins-ci.org/commit/copyartifact-plugin/53462816b1d9f3455a3422d89bc5d6feaff274f1 Log: [FIXED JENKINS-26694] ParameterBuildFilter now works also for WorkflowRun.

          Code changed in jenkins
          User: ikedam
          Path:
          src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
          src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java
          http://jenkins-ci.org/commit/copyartifact-plugin/1308f8da0170ff3010054417bdcf5d88bd536df4
          Log:
          JENKINS-26694 Make tests succeed on Windows: HudsonTestCase using workflow-1.1 fails for JENKINS-26030.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java http://jenkins-ci.org/commit/copyartifact-plugin/1308f8da0170ff3010054417bdcf5d88bd536df4 Log: JENKINS-26694 Make tests succeed on Windows: HudsonTestCase using workflow-1.1 fails for JENKINS-26030 .

          Code changed in jenkins
          User: ikedam
          Path:
          src/main/java/hudson/plugins/copyartifact/ParametersBuildFilter.java
          src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java
          http://jenkins-ci.org/commit/copyartifact-plugin/7802e455a2479f545e5f7fa58d1ca6fdd8871028
          Log:
          Merge pull request #59 from ikedam/feature/JENKINS-26694_ParametersBuildFilterForWorkflow

          JENKINS-26694 Make ParameterBuildFilter applicable to WorkflowJobs.

          Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/ec41cbdd914d...7802e455a247

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/main/java/hudson/plugins/copyartifact/ParametersBuildFilter.java src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java http://jenkins-ci.org/commit/copyartifact-plugin/7802e455a2479f545e5f7fa58d1ca6fdd8871028 Log: Merge pull request #59 from ikedam/feature/ JENKINS-26694 _ParametersBuildFilterForWorkflow JENKINS-26694 Make ParameterBuildFilter applicable to WorkflowJobs. Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/ec41cbdd914d...7802e455a247

          ikedam added a comment -

          Fixed in copyartifact-1.35.
          It will be available in a day. Please try that.

          ikedam added a comment - Fixed in copyartifact-1.35. It will be available in a day. Please try that.

            ikedam ikedam
            jamesvl James VL
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: