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

absolute path (with folders) throws exception

XMLWordPrintable

      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

          Matt Sheehan created issue -
          Jesse Glick made changes -
          Assignee New: Nicolas De Loof [ ndeloof ]

          Jesse Glick added a comment -

          First of all, (Job) Jenkins.getInstance().getItemByFullName(part) should be Jenkins.getInstance().getItemByFullName(part, Job.class). But then the code is apparently wrong anyway: from an initial ctx of some random folder, the first part is folder, so ctx.getItem(part) is null, and then getItemByFullName(part) should be that folder. Perhaps what you meant was to pass in the original projectName.

          Jesse Glick added a comment - First of all, (Job) Jenkins.getInstance().getItemByFullName(part) should be Jenkins.getInstance().getItemByFullName(part, Job.class) . But then the code is apparently wrong anyway: from an initial ctx of some random folder, the first part is folder , so ctx.getItem(part) is null , and then getItemByFullName(part) should be that folder. Perhaps what you meant was to pass in the original projectName .
          Jesse Glick made changes -
          Labels New: folders

          Nicolas De Loof added a comment -

          @Jesse ctx is set to jenkins.instance if jobName starts with '/' so ctx.getItem(part) should not be null

          added some test cases to cover folders support, can't reproduce this error
          https://github.com/jenkinsci/copyartifact-plugin/commit/201f613d7dfe82f2abed8e5e93454b3e09214ee6

          Nicolas De Loof added a comment - @Jesse ctx is set to jenkins.instance if jobName starts with '/' so ctx.getItem(part) should not be null added some test cases to cover folders support, can't reproduce this error https://github.com/jenkinsci/copyartifact-plugin/commit/201f613d7dfe82f2abed8e5e93454b3e09214ee6

          Jesse Glick added a comment -

          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.

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

          Jesse Glick added a comment -

          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.

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

          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.

          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.

          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.

          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.

            ndeloof Nicolas De Loof
            mattsheehan Matt Sheehan
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: