-
Bug
-
Resolution: Fixed
-
Major
Using absolute path like
Project Name = /folder/job1
results in:
FATAL: com.cloudbees.hudson.plugins.folder.Folder cannot be cast to hudson.model.Job java.lang.ClassCastException: com.cloudbees.hudson.plugins.folder.Folder cannot be cast to hudson.model.Job at hudson.plugins.copyartifact.CopyArtifact$EnvAction.getProject(CopyArtifact.java:471) at hudson.plugins.copyartifact.CopyArtifact$EnvAction.add(CopyArtifact.java:450) at hudson.plugins.copyartifact.CopyArtifact$EnvAction.access$400(CopyArtifact.java:444) at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:267) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:584) at hudson.model.Run.execute(Run.java:1575) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237)
[JENKINS-19833] absolute path (with folders) throws exception
I can think one way this could happen: if projectName were actually folder/job1 without the leading slash, in which case again the use of part rather than projectName seems incorrect.
Matt Sheehan
added a comment - Cripes! You are correct it is actually folder/job1. My mistake. That worked in 1.27 but not in 1.28.
Matt Sheehan
added a comment - Cripes! You are correct it is actually folder/job1. My mistake. That worked in 1.27 but not in 1.28. I got the same exception, but I was using a relative path and expecting it to fall back to absolute resolution when the item wasn't found.
Here's a test case to reproduce this particular behaviour:
https://github.com/wgreven/copyartifact-plugin/commit/d2d50eb8a1b256b4b051044cdd98e60c0ac5a7f7
The reason for using the relative path is that I copy the project name from the UpstreamCause. I added the initial '/' now myself.
Wilco Greven
added a comment - - edited I got the same exception, but I was using a relative path and expecting it to fall back to absolute resolution when the item wasn't found.
Here's a test case to reproduce this particular behaviour:
https://github.com/wgreven/copyartifact-plugin/commit/d2d50eb8a1b256b4b051044cdd98e60c0ac5a7f7
The reason for using the relative path is that I copy the project name from the UpstreamCause. I added the initial '/' now myself. I can confirm this bug when using relative paths as well. It only started to happen once I updated Jenkins and the Folders plugins.
I currently am running:
Jenkins: 1.534
Folders: 3.14
I am NOT able to workaround the problem at this time. Please advise.
CORRECTION: I AM able to workaround the problem by using absolute paths within the Copyartifact config. This only appears when relative job paths are used.
Myles Steinhauser
added a comment - - edited I can confirm this bug when using relative paths as well. It only started to happen once I updated Jenkins and the Folders plugins.
I currently am running:
Jenkins: 1.534
Folders: 3.14
I am NOT able to workaround the problem at this time. Please advise.
CORRECTION: I AM able to workaround the problem by using absolute paths within the Copyartifact config. This only appears when relative job paths are used. We're experiencing the same issue since we upgraded to Jenkins 1.509.31 & Folders 3.14 & Folders Plus 1.8. I can't seem to find a work-around that works for us - if we're trying to copy artifacts from the workspace of the last successful build of a different project that ran on another build node, I'm not sure how I can set an absolute path.
Say the complete tree that I want to get artifacts from is:
http://jenkins/job/Top/job/Middle/job/BottomA/
I'm currently here:
http://jenkins/job/Top/job/Middle/job/BottomB/
Under "Copy Artifacts From Another Project" we had:
"BottomA" entered, and "Copy from WORKSPACE of latest completed build".
We got the exception above (about not being able to cast to hudson.model.Job).
I changed it to "/Top/Middle/BottomA" and it still errored.
Any ideas? If not, is there a version we can fall back to?
UPDATE: It was the next copy artifact task that was failing; it was "TopC/MiddleC/BottomC" and I put a / in front of it and now we're working. Thanks!
Kelly Schoenhofen
added a comment - - edited We're experiencing the same issue since we upgraded to Jenkins 1.509.31 & Folders 3.14 & Folders Plus 1.8. I can't seem to find a work-around that works for us - if we're trying to copy artifacts from the workspace of the last successful build of a different project that ran on another build node, I'm not sure how I can set an absolute path.
Say the complete tree that I want to get artifacts from is:
http://jenkins/job/Top/job/Middle/job/BottomA/
I'm currently here:
http://jenkins/job/Top/job/Middle/job/BottomB/
Under "Copy Artifacts From Another Project" we had:
"BottomA" entered, and "Copy from WORKSPACE of latest completed build".
We got the exception above (about not being able to cast to hudson.model.Job).
I changed it to "/Top/Middle/BottomA" and it still errored.
Any ideas? If not, is there a version we can fall back to?
UPDATE: It was the next copy artifact task that was failing; it was "TopC/MiddleC/BottomC" and I put a / in front of it and now we're working. Thanks! @jesse remember the "projectName" may include parmeters or matrix-axe as last part, as it uses "/" separator for this. So can't just use Jenkins.getInstance().getItemByFullName(jobName, Job.class), need to lookup each subelement up to first Job instance
So, as a resume, this issue is "foo" MAY be considered equivalent to "/foo" when used from a Folder. Looks buggy to me, and will break if you later create a "foo" item inside folder, but can understand the backward compatibility issue.
the "projectName" may include parmeters or matrix-axe as last part, as it uses "/" separator for this
Since 6243f6b (JENKINS-13222) in 1.26, parameters are in a separate field. Matrix axes are still in the project field, but that is fine because getItemByFullName works for that.
Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
http://jenkins-ci.org/commit/copyartifact-plugin/5153c276e923ea7e0fd73ab9a7adacad4261c4ba
Log:
[FIXED JENKINS-19833] support (mostly) absolute path for job name
i.e. job name can be fully qualified but not start with "/"
required for backward compatibility
So then I do not know how you would reproduce it, but the code still looks wrong. Assuming projectName is /folder/job1, and there is a top-level folder folder and a job within it named job1, somehow Jenkins.getInstance().getItem("folder") is returning null, which should not happen. But if it does happen, you are calling Jenkins.getInstance().getItemByFullName("folder", Job.class), which makes no sense; you meant to call Jenkins.getInstance().getItemByFullName("folder/job1", Job.class).
Really I am not sure why if projectName.startsWith("/") you do not immediately return Jenkins.getInstance().getItemByFullName(projectName.substring(1), Job.class and bypass the loop.