-
Improvement
-
Resolution: Unresolved
-
Major
-
Any environment...
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.
- is duplicated by
-
JENKINS-16405 suppert basedir, The basedir configuration is similar to the ArtifactDeployer plug-in provides
- Open
-
JENKINS-14367 Copy Artifact / Archive Artifact: archive as root
- Closed
- is related to
-
JENKINS-48489 ability to specify a path prefix to archiveArtifacts
- Open
- links to