Hi Irwin, We took two approaches to a similar requirement.
1. For common code that are built as libraries, we build separately. As this code does not change too often, we assume that the libraries are available for the other builds/jobs. 2. We used the Multi-Job plugin to 'group' and 'order' the build steps for each Job. I hope that this may help, Mgimza On Tue, Jan 8, 2013 at 9:01 AM, Jiurgol Irwin <jiur...@gmail.com> wrote: > We use Jenkins using the Team Foundation Server plugin for continuous > integration of our .NET solutions.**** > > We have the following folder structure in our source control:**** > > ** ** > > Root**** > > |**** > > |- Common Code A**** > > |**** > > |- Common Code B**** > > | **** > > |- Project A (build file exists in this folder which builds code in > Project A as well as in the 2 Common Code folders)**** > > |**** > > |- Project B (build file exists in this folder which builds code in > Project B as well as in the 2 Common Code folders)**** > > **** > > We are not sure of the best way to set up our Jobs. We ideally want one > job for Project A & one for Project B. The problem is that because we also > build code in the common code folders, we have to set our workspace to be > at the root level so that the common code is also downloaded and built. * > *** > > ** ** > > While we could set up each Jenkins workspace to get all the code from the > root we are concerend about the length of time to build, how much diskspace > this would take and also worried about potential file locking issues.**** > > ** ** > Have you any recommendations about how we could set up our jobs? Thanks! >
