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

Details

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

Activity

I've also seen this issue. In 1.26, the tag name changed from projectName to project. I edited all our config.xml files manually and it does the trick. Bad news is, that saving the configuration in Jenkins throws an exception.

Max Wahler
added a comment - 2013-04-29 09:24 I've also seen this issue. In 1.26, the tag name changed from projectName to project. I edited all our config.xml files manually and it does the trick. Bad news is, that saving the configuration in Jenkins throws an exception.

Alan Birtles
added a comment - 2013-06-05 08:53 I've upgraded from 1.25 to 1.27 and it seems to automatically perform the upgrade when a project is built. Unfortunately I modified a few jobs before they were built so encountered this bug

ikedam
added a comment - 2013-06-10 09:15 This seems caused by 6243f6bcd5 , splitting projectName into project and parameters .
This can be fixed with readResolve() , as described in https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility

ikedam
added a comment - 2013-06-11 14:22 There seems a little complex problem:
project names in Copy Artifact < 1.26 accept axis parameters and build parameters by splitting with a slash.
project names in Copy Artifact >= 1.26 accept only axis parameters, no longer build parameters.
This is the same bahavior to Jenkins core.
So readResolve() cannot simply split a old project name into a project name and parameters. It must consider whether values after a slash are axis parameters or build parameters.

ikedam
added a comment - 2013-07-18 08:08 I posted a pull request.
For it is difficult to fix the configuration automatically, a warning message will be displayed.
https://github.com/jenkinsci/copyartifact-plugin/pull/21
But it is not reviewed for a month...
There also left some other reviews, and no maintainer seems available...

The upgrade is automatic if you simply build your project after updating the plugin. You must not configure the project before building it. I closed PR #21 since it does not really solve the problem; there are various ways the storage could be upgraded automatically without requiring a build.

Jesse Glick
added a comment - 2013-07-18 15:32 The upgrade is automatic if you simply build your project after updating the plugin. You must not configure the project before building it. I closed PR #21 since it does not really solve the problem; there are various ways the storage could be upgraded automatically without requiring a build.

> The upgrade is automatic if you simply build your project after updating the plugin.

I know that and that cannot resolve the problem at all.
The problem is that, modifying the configuration before building breaks the configuration, and there is a case that a project administrator and a Jenkins administrator are different.

> there are various ways the storage could be upgraded automatically without requiring a build.

Do you plan to work that?
Or please let me know the outline of those ways, and I work it.

I think the difficulty is the case a project is not contained in ItemGroup other than Jenkins, and cannot be enumerated with Jenkins#getItems.
I have no idea about the proper way to visit all projects.

ikedam
added a comment - 2013-07-18 23:08 > The upgrade is automatic if you simply build your project after updating the plugin.
I know that and that cannot resolve the problem at all.
The problem is that, modifying the configuration before building breaks the configuration, and there is a case that a project administrator and a Jenkins administrator are different.
> there are various ways the storage could be upgraded automatically without requiring a build.
Do you plan to work that?
Or please let me know the outline of those ways, and I work it.
I think the difficulty is the case a project is not contained in ItemGroup other than Jenkins , and cannot be enumerated with Jenkins#getItems .
I have no idea about the proper way to visit all projects.

Jesse Glick
added a comment - 2013-07-19 15:57 Do you plan to work [on] that?
Not currently.
please let me know the outline of those ways
Probably something like
@Initializer(after=JOB_LOADED)
public static void upgradeAll() {
for (AbstractProject p : Jenkins.getInstance().getAllItems(AbstractProject.class)) {
try {
ListenerImpl.getCopiers(p); // calls upgradeIfNecessary as a side effect
} catch (IOException x) {
Logger.getLogger(CopyArtifact. class. getName()).log(Level.WARNING, "could not upgrade configuration of " + p, x);
}
}
}
except you would also want to set a persisted flag in CopyArtifactPlugin so that this work is only done once, not after every startup.

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:

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:

Michael Prokop
added a comment - 2013-11-14 15:40 - 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.

Jesse Glick
added a comment - 2013-11-14 16:11 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.