Hi,
we are currently evaluating the GO Enterprise edition 2.1.0(11943-65dd4ee228d8) and are wondering about the "fetchartifact" behaviour.
From the go documentation:
<fetchartifact stage="dev" job="unit" srcdir="pkg" dest="lib"/>
Fetch all artifacts in the directory 'pkg' from the previous stage in the same pipeline and put them under the directory 'lib'
So if "pkg" contained e.g. foo.jar and bar.jar, I would expect that those artifacts end up in "lib". However, the whole "pkg" folder is copied to "lib" so that you end up having "lib/pkg/foo.jar" and "lib/pkg/bar.jar". Is that the intended behaviour? So if we need the jars directly under "lib", is the only way to achieve that to specify them all separately and use the "srcfile" attribute? That would be quite tedious especially if you've got a lot of artifacts...
Cheers,
Christof
fetchartifact behaviour
Comments
3 comments
Hi Christof,
Yes, you are right. Since "fetchartifact" does not support wildcards as source, it means that you have to specify each artifact separately for the problem you are trying to solve.
We have a story in our backlog to fix this. It is currently prioritized for our 3.0 release (scheduled for release in Q3 this year).
- Rajesh
Thanks for the info.
Yep, wildcards in the source spec sounds like the most flexible solution as you don't always want all the artifacts but also don't want to list them all individually (and sometimes you can't as the names of some artifacts might not be static because they contain a version number etc).
Well, guess we have to work around it for now and wait till Q3.
Cheers,
Christof
Christof
One way to solve this is to create the artifact called lib from pkg, <artifact src="pkg" dest="lib" />, then fetch artifact becomes
<fetchartifact stage="dev" job="unit" srcdir="lib"/> and then you don't get the pkg folder. I agree i don't see much use for the dest attribute on fetchartifact as it tends to just mess up the structure as you pass artifacts along the pipelines.
- Ian
Please sign in to leave a comment.