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

Archive the artifacts should allow specifying the target artifacts path

      This is a problem that was mentioned on multiple occasions and strangely enough, it was never really answered or sometimes not
      understood.

      Let me provide some explanation:

      Job A
      Produces the following artifact:
      Build/release/x86/<multiple dlls>
      build/release/x86/fr/<some resource dll>
      build/release/x86/ru/<some resource dll>

      Job B
      Needs job A artifacts in the following folder: "lib/myJobA/"
      However it should not get "build/release/x86" Job A artifact folder. What we really want here is:
      lib/myJobA/<multiple dlls>
      lib/myJobA/fr/<some resource dll>
      lib/myJobA/ru/<some resource dll>

      However, unless I'm missing something obvious, neither "Archive the artifacts" nor "Copy artifacts from another project" will let you do that.
      "Archive the artifacts" will mirror the whole specified path "Build/release/x86/..." and "Copy artifacts from another project" will also copy the whole path to the specified target. (ie: lib/myJobA/build/release/x86/<multiple dlls>)

      "flatten" option will not help as it will not keep "fr" and "ru" folder.
      For that specific example, a possible workaround is to create 3 separate "Copy artifacts" build steps and to copy each folder
      individually in the specific target folder (using the flatten option). However, not only it is quite cumbersome, but also makes it quite difficult to refactor the job at a later time with so much data specific to jobA workspace.
      I suppose that a script could help (I'm new to Jenkis) but I believe that this should be a core feature of Jenkins "Archive the
      artifacts" (even though it would be possible to implement it at the "copy artifact" level, it seems much better to have jobB agnostic of jobA workspace specifics).

      Teamcity has a smart approach to handle this:
      If you specify: build/release/x86/*/.dll, it will omit "build/release/x86/" when archiving the artifacts.

      It also allows for more explicit target definition by using "=>" (ie: windows/.zip => winfiles,unix/.tgz => linuxFiles)
      Having at least the first option seems a must-have. In order to keep compatibility, it should be possible to check an option: [x] rebase (or re-root or whatever sounds good in English). By checking this option (unchecked by default), one would agree to have the artifacts path interpreted à la Teamcity.

      Hope all this makes sense.

          [JENKINS-12379] Archive the artifacts should allow specifying the target artifacts path

          Daniel Beck added a comment - - edited

          Would the proposed solution in the attached screenshots work for everyone? It essentially splits pattern and user-defined common prefix in two. It's not as powerful as the TeamCity approach, but should cover almost all use cases without having to resort to shell scripts.

          Daniel Beck added a comment - - edited Would the proposed solution in the attached screenshots work for everyone? It essentially splits pattern and user-defined common prefix in two. It's not as powerful as the TeamCity approach, but should cover almost all use cases without having to resort to shell scripts.

          Daniel Beck added a comment -

          I guess not.

          Daniel Beck added a comment - I guess not.

          Daniel Beck added a comment -

          As I need this feature now, implementing as proposed above.

          Daniel Beck added a comment - As I need this feature now, implementing as proposed above.

          Daniel Beck added a comment -

          Daniel Beck added a comment - Proposed solution at https://github.com/jenkinsci/jenkins/pull/1493

          Greg Roper added a comment -

          I think this would be a perfect solution for my needs.

          Greg Roper added a comment - I think this would be a perfect solution for my needs.

          Drew Horn added a comment -

          Hi danielbeck,

          Looks like this thread lost some traction. The proposed solution looks good, is there anything I can do to help get the pull request pushed through?

          Thanks!

          Drew Horn added a comment - Hi danielbeck , Looks like this thread lost some traction. The proposed solution looks good, is there anything I can do to help get the pull request pushed through? Thanks!

          Daniel Beck added a comment -

          Thanks for the reminder. I'll try to revisit Jesse's objection pointing to continued user interest.

          Daniel Beck added a comment - Thanks for the reminder. I'll try to revisit Jesse's objection pointing to continued user interest.

          miq added a comment -

          I have exactly the same problem and would love to see a fix upstream.

          miq added a comment - I have exactly the same problem and would love to see a fix upstream.

          Tammy Osborn added a comment -

          I just spent several hours trying to resolve this exact same problem where we have nested subfolders we need to deploy without duplicating the parent directory structure. This would be a definite improvement in the functionality. Hope to see the enhancement implemented soon.

          Tammy Osborn added a comment - I just spent several hours trying to resolve this exact same problem where we have nested subfolders we need to deploy without duplicating the parent directory structure. This would be a definite improvement in the functionality. Hope to see the enhancement implemented soon.

          Sorin Sbarnea added a comment -

          I think that the correct PR is https://github.com/jenkinsci/jenkins/pull/1878 but is more than 2 years old and needs rebase and some work done to it.

          Anyone willing to takeover if danielbeck cannot?

          I am big afraid the the Windows testing is outside my power, I no longer have even a VM with it.

          Sorin Sbarnea added a comment - I think that the correct PR is https://github.com/jenkinsci/jenkins/pull/1878  but is more than 2 years old and needs rebase and some work done to it. Anyone willing to takeover if danielbeck cannot? I am big afraid the the Windows testing is outside my power, I no longer have even a VM with it.

            Unassigned Unassigned
            frederic_latour Frederic Latour
            Votes:
            38 Vote for this issue
            Watchers:
            35 Start watching this issue

              Created:
              Updated: