If your Project B
expects artifacts in a certain structure, then Project A
should provide them in that structure. As you mentioned, Archive Artifacts post-build action does not let you specify alternative location for artifacts, but it does preserve their relative structure at the time of archiving.
So, in Project A
, after the building step (or within it, depending on how you call it), organize the artifacts before Archive Artifacts is executed.
You can write a simple script, that will take your build artifacts, and copy them under a discrete/unique folder, let's call it release
folder. Then tell Archive Artifacts post-build action to archive only the release
folder, like path\to\release\*.*
It is upto your script to organize the artifacts in the release
folder in a structure that would be suitable for Project B
.
BTW, nothing says you cannot move this logic to Project B
, and have it Copy Artifacts from Project A
as is, and then run a script on Project B
that will move them into a, let's say, for_installer
folder and then supply that folder to the packaging process for Project B
As for "referencing" the artifacts: The Copy Artifacts plugin will copy artifacts of a particular build (by number or label). It defaults to location of archived artifacts (on the "from" part), and to WORKSPACE
(on the "to" part). In the example above, if your Project A
organized the artifacts into release
folder, and your archived that as path\to\release\*
, then on the Copy Artifacts step, set "Artifacts to Copy" as *
, and leave "Target Directory" blank to be placed directly in Workspace, or specify a directory