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

Artifactory plugin creates directories instead of uploading files

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • artifactory-plugin
    • None
    • Jenkins 1.625.3
      Artifactory plugin 2.4.7
      Artifactory OSS (latest docker image: 29d2cd2e846a)

      My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
      During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
      Publishing rules are the following (yes, there are version-named directories as the dest):

      /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
      /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
      

      I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
      I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
      Also raised: https://www.jfrog.com/jira/browse/HAP-690

      I couldn't find a workaround so this is blocking me at the moment.

      UPDATE: all works fine if I don't use "Deployment properties" option.

          [JENKINS-32869] Artifactory plugin creates directories instead of uploading files

          Nickolay Rumyantsev created issue -
          Nickolay Rumyantsev made changes -
          Description Original: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.

          I couldn't find a workaround so this is blocking me at the moment.
          New: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
          Also raised: https://www.jfrog.com/jira/browse/HAP-690

          I couldn't find a workaround so this is blocking me at the moment.
          Nickolay Rumyantsev made changes -
          Environment Original: Jenkins 1.625.3
          Artifactory plugin 2.4.7 (2.2.4 too)
          Artifactory OSS (latest docker image: 29d2cd2e846a)
          New: Jenkins 1.625.3
          Artifactory plugin 2.4.7
          Artifactory OSS (latest docker image: 29d2cd2e846a)
          Nickolay Rumyantsev made changes -
          Description Original: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
          Also raised: https://www.jfrog.com/jira/browse/HAP-690

          I couldn't find a workaround so this is blocking me at the moment.
          New: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
          Also raised: https://www.jfrog.com/jira/browse/HAP-690

          I couldn't find a workaround so this is blocking me at the moment.

          UPDATE: all works fine if I don't use "Deployment properties" option.
          Nickolay Rumyantsev made changes -
          Priority Original: Blocker [ 1 ] New: Major [ 3 ]
          Nickolay Rumyantsev made changes -
          Description Original: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
          Also raised: https://www.jfrog.com/jira/browse/HAP-690

          I couldn't find a workaround so this is blocking me at the moment.

          UPDATE: all works fine if I don't use "Deployment properties" option.
          New: My job builds some tgz and rpms. I configured it to use Artifactory plugin as a Generic deployer to my test Artifactory instance.
          During the execution plugin reports in the log that it found the artifacts and deployed them successfully. But it ran too fast so I check the artifacts on the Artifactory page. There I saw that instead of files there were directories with the same names!
          Publishing rules are the following (yes, there are version-named directories as the dest):
          {code:java}
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.COREOS.tgz=>com/foo/bar/coreos/1.5.0.0-155.COREOS
          /jenkins/workspace/BuildJob/RPMS/x86_64/1.5.0.0-155.RHEL.rpm=>com/foo/bar/rhel7/1.5.0.0-155.RHEL
          {code}
          I also tried appending the filename to the each rule, and a trailing slash too but it didn't help.
          I found a stackoverflow question about the same issue but there is not much information: http://stackoverflow.com/questions/30633080/artifactory-creating-folders-instead-of-deploying-artifact.
          Also raised: https://www.jfrog.com/jira/browse/HAP-690

          I couldn't find a workaround so this is blocking me at the moment.

          *UPDATE:* all works fine if I don't use "Deployment properties" option.
          Daniel Beck made changes -
          Assignee Original: yossis [ yossis ] New: Eyal Ben Moshe [ eyalbe ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 168566 ] New: JNJira + In-Review [ 183180 ]

            eyalbe Eyal Ben Moshe
            nickolayr Nickolay Rumyantsev
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: