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

CopyArtifacts fails with relative paths

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • copyartifact-plugin
    • None
    • Jenkins 2.303.3
      Copy Artifact Plugin 1.46.2

      When using a relative path in "Permission to Copy Artifact" the other project is not allowed to copy artifacts. Using an absolute path works as expected.

      Consider the following scenario with two jobs

      /folder/CreateArtifacts
      /folder/CopyArtifacts

      Using the following "Permission to Copy Artifact" in CreateArtifacts works as expected

      • *
      • CopyArtifacts
      • /*
      • /folder/*
      • /folder/CopyArtifacts

      But, the following does not work:

      • ./*
      • ./CopyArtifacts
      • ../*
      • ../folder/*
      • ../folder/CopyArtifacts

      Maybe, the first two cases might not work by design (and the exact same behavior can be achieved by using "*" and "CopyArtifacts" respectively).

      But, the other permissions should work. When using a deeper folder-structure this is needed. When using "./CopyArtifacts" and "../folder/CopyArtifacts" no "Unable to find project" warning is shown in the configuration. It seems the validator is able to find the jobs with this path just fine.

          [JENKINS-67400] CopyArtifacts fails with relative paths

          Mark added a comment -

          I analyzed the issue. The reason for the odd behavior is that the runtime code will only accept a relative path if it is the shortest possible relative path between source project and target project.

          In your examples, both projects reside in the same folder, and therefore the relative path specification without any folders will work.

          If you had the following jobs:

          • /folder/CreateArtifacts
          • /CopyArtifacts1
          • /anotherFolder/CopyArtifacts2

          You could specify the permissions as

          • ../CopyArtifacts1
          • ../anotherFolder/CopyArtifacts2

          (or as absolute paths)

          The reason why the validator supports your specs is that it works the other way around: it asks Jenkins if there is some job matching the pattern (and Jenkins seems to do a more sophisticated resolution). This however cannot directly be reused because it only checks whether some/any job matches, but at runtime we need to know if that particular job does.

          I think it should not be too hard to fix that issue, but only the other hand I would consider it only a low one, as there is some valid/working relative spec.

          Mark added a comment - I analyzed the issue. The reason for the odd behavior is that the runtime code will only accept a relative path if it is the shortest possible relative path between source project and target project. In your examples, both projects reside in the same folder, and therefore the relative path specification without any folders will work. If you had the following jobs: /folder/CreateArtifacts /CopyArtifacts1 /anotherFolder/CopyArtifacts2 You could specify the permissions as ../CopyArtifacts1 ../anotherFolder/CopyArtifacts2 (or as absolute paths) The reason why the validator supports your specs is that it works the other way around: it asks Jenkins if there is some job matching the pattern (and Jenkins seems to do a more sophisticated resolution). This however cannot directly be reused because it only checks whether some/any job matches, but at runtime we need to know if that particular job does. I think it should not be too hard to fix that issue, but only the other hand I would consider it only a low one, as there is some valid/working relative spec.

            markreiche Mark
            gordin Christoph VogtlÃĪnder
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: