-
Bug
-
Resolution: Fixed
-
Critical
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.
- is related to
-
-
- Closed
-
[JENKINS-17680] Upgrade to new Copy Artifacts version erases all job names to copy from
Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testProjectNameSplit.zip
http://jenkins-ci.org/commit/copyartifact-plugin/b42c2158119f8c8b06d0562bbd1d9bf7b7ee5f49
Log:
JENKINS-17680 Upgrade is applied also to MatrixProject.
Code changed in jenkins
User: ikedam
Path:
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testWrappedCopierProjectNameSplit.zip
http://jenkins-ci.org/commit/copyartifact-plugin/3c6babe659e45386de6db676054d4eb0b9b9de4a
Log:
JENKINS-17680 Added a test for verifying upgrading on building works.
Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
http://jenkins-ci.org/commit/copyartifact-plugin/355aedb310d61d2f26e235630b4fc99c7c886e73
Log:
JENKINS-17680 Changed a confusiong method name.
Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testProjectNameSplit.zip
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testWrappedCopierProjectNameSplit.zip
http://jenkins-ci.org/commit/copyartifact-plugin/f13ba75afffcd971475875873fefc398600a084b
Log:
Merge pull request #23 from ikedam/feature/JENKINS-17680-3
JENKINS-17680 Upgrade configurations from version 1.25
Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/428d32a6be6b...f13ba75afffc
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.
ikedam
added a comment - Fixed in Copy Artifact 1.28. 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:
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. 
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. 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.
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/).
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/ ). 
Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/main/java/hudson/plugins/copyartifact/CopyArtifactUpgradeListener.java
http://jenkins-ci.org/commit/copyartifact-plugin/854deb121eace1d0f4a90664a6d2d2ad733e0d61
Log:
JENKINS-17680use @Initializer instead of ItemListener.