I have what I take to be problem related to Fernando's. And I think the solution should be the same. So here is my explanation.
I have essentially one svn repository. Its checkout is used for a multi configuration job. The user axes provide variants of my Ant build. The build is part of the checkout. It knows how to handle these variants itself, if provided with the current axes configuration as Ant properties, which the multi configuration job promised to do. By default, Jenkins checks out the svn repository N times. N being the number of all combinations, e.g. axis1 contains 2 items, axis2 contains 3 items, yielding 6 combinations. This is a pain. Jenkins produces N checkouts, where I require only one. This results in overhead for the initial checkout as well as subsequent updates. How to fix that? I have found no solution so far elsewhere. I think the typical way to handle this in subversion is to make each > project that builds separately have its own trunk/branches/tags tree > and every part that needs to include components from a separate area > would use svn externals to pull them into a checkout. This seems too complicated for my use case. Do you agree? Yes, that is the layout your job requests. But what I meant was that > on the 2nd and subsequent runs of this job, jenkins should be doing > an 'svn update' into those existing workspaces which should not be an > expensive operation even if you have to repeat it a few times. Alright. So there just is no way to have a multi configuration job reuse the same checkout? Regards, Alexander -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
