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

Upgrade to new Copy Artifacts version erases all job names to copy from

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After an update to the new copy artifacts version 1.26 existing configurations are broken because all job names to copy artifacts from are empty. The configuration files still contain the correct names, e.g.:

      <hudson.plugins.copyartifact.CopyArtifact plugin="copyartifact@1.25">
      <projectName>rsc-trunk/label=$label</projectName>
      <filter>*/.tar.gz</filter>
      <target>upstream</target>
      <selector class="hudson.plugins.copyartifact.StatusBuildSelector"/>
      <flatten>true</flatten>
      </hudson.plugins.copyartifact.CopyArtifact>

      As you can see, most of our jobs use variables in the projectName tag. Maybe this is the reason for the problem. I actually cannot find a job without this, so I cannot verify this idea.

      With 1.25 everything is ok.

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: ikedam
            Path:
            src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
            src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
            http://jenkins-ci.org/commit/copyartifact-plugin/f468296f905b23eebf0a36790612b100c8d7a8cd
            Log:
            Fixed unnecessary codes added by changes for JENKINS-17680.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/main/java/hudson/plugins/copyartifact/CopyArtifact.java src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java http://jenkins-ci.org/commit/copyartifact-plugin/f468296f905b23eebf0a36790612b100c8d7a8cd Log: Fixed unnecessary codes added by changes for JENKINS-17680 .
            Hide
            ikedam ikedam added a comment -

            Fixed in Copy Artifact 1.28.

            Show
            ikedam ikedam added a comment - Fixed in Copy Artifact 1.28.
            Hide
            mika Michael Prokop added a comment - - edited

            If the config.xml of a job includes both the project and projectName settings, being identical like:

            <project>demojob/architecture=$architecture</project>
            <projectName>demojob/architecture=$architecture</projectName>

            then it fails to run with current version(s) of the Copy Artifacts plugin (1.28) because no artifacts can be copied from axis architecture of demojob ("Unable to find a build for artifact copy from: demojob") even though the artifacts are there.

            The problem about it is that the web interface displays the correct configuration (Project Name: "demojob/architecture=$architecture" and "Parameter filters" being empty) but the wrong configuration is actually used (Project Name: "demojob" and "Parameter filters: "architecture=$architecture"). When you execute the job the Copy Artifacts plugin automatically converts the configuration to:

            <project>demojob</project>
            <parameters>architecture=$architecture</parameters>

            which is something different and doesn't work. When you manually select "Configure" on the original job (the one with project + projectName settings being identical) in the web interface and then click on "Save" it's fine though.

            This is a problem for folks generating config.xml in an automated way (where you never manually click "Configure" but generate the config.xml from scratch). The mentioned configuration is used for example in jenkins-job-builder:

            https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/builders.py#L122

            I can share configurations for jenkins-job-builder to easily reproduce the behavior if needed.

            Any idea how a smoother upgrade path could be possible? I'm pretty sure this is breaking quite some setups.

            Show
            mika Michael Prokop added a comment - - edited If the config.xml of a job includes both the project and projectName settings, being identical like: <project>demojob/architecture=$architecture</project> <projectName>demojob/architecture=$architecture</projectName> then it fails to run with current version(s) of the Copy Artifacts plugin (1.28) because no artifacts can be copied from axis architecture of demojob ("Unable to find a build for artifact copy from: demojob") even though the artifacts are there. The problem about it is that the web interface displays the correct configuration (Project Name: "demojob/architecture=$architecture" and "Parameter filters" being empty) but the wrong configuration is actually used (Project Name: "demojob" and "Parameter filters: "architecture=$architecture"). When you execute the job the Copy Artifacts plugin automatically converts the configuration to: <project>demojob</project> <parameters>architecture=$architecture</parameters> which is something different and doesn't work. When you manually select "Configure" on the original job (the one with project + projectName settings being identical) in the web interface and then click on "Save" it's fine though. This is a problem for folks generating config.xml in an automated way (where you never manually click "Configure" but generate the config.xml from scratch). The mentioned configuration is used for example in jenkins-job-builder: https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/builders.py#L122 I can share configurations for jenkins-job-builder to easily reproduce the behavior if needed. Any idea how a smoother upgrade path could be possible? I'm pretty sure this is breaking quite some setups.
            Hide
            jglick Jesse Glick added a comment -

            The projectName field is deprecated, and may not be used together with project; there is a one-way conversion of projectName (which gets deleted) to project plus parameters. If jenkins-job-builder writes out a configuration including both fields then it is simply buggy.

            Show
            jglick Jesse Glick added a comment - The projectName field is deprecated, and may not be used together with project ; there is a one-way conversion of projectName (which gets deleted) to project plus parameters . If jenkins-job-builder writes out a configuration including both fields then it is simply buggy.
            Hide
            mika Michael Prokop added a comment -

            Alright, sad but fair enough - thanks for clarification. I've filed a patch upstream against jenkins-job-builder (FTR: https://review.openstack.org/#/c/56412/).

            Show
            mika Michael Prokop added a comment - Alright, sad but fair enough - thanks for clarification. I've filed a patch upstream against jenkins-job-builder (FTR: https://review.openstack.org/#/c/56412/ ).

              People

              • Assignee:
                ikedam ikedam
                Reporter:
                languitar Johannes Wienke
              • Votes:
                3 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: