I wonder if you could use a series of docker images to provide a location which can be polluted by installed copies of build articles. It seems like a docker image (container based virtualization, available in Debian Jessie) would let you contaminate the specific virtual machine you need, without requiring that you contaminate the original slave or the original master.
On Sat, Nov 1, 2014 at 8:24 PM, John Mellor <john.mel...@gmail.com> wrote: > I've just inherited a complex product suite build environment, and am in > the process of moving it from a custom build hack into a Jenkins build > environment. Company politics aside, it seems like a more scalable way to > do things. The product suite runs on and is also built on multiple > releases of a Debian platform. I can easily build any one of the 187 > components as a simple C++ automake project, but only if I install much of > the previously-built product from earlier steps in the build process. If I > want to build the whole product suite for a release, I'm unsure how to > approach this correctly. Any and all help is hugely appreciated! > > The problem is that about half of the individual project builds in the > product suite have one or more compile-time dependencies on other builds > earlier in the tree. Each of the 187 builds produces a .deb installation > deliverable, and at this point, the only means of getting the dependencies > available for higher-level builds is to [gag!] "pollute" the the build > machine and install them (manually at this point, using sudo dpkg -i). > This can obviously be automated in a postbuild step, and should work ok for > building a branch that always move forward such as the next release branch, > but has several obvious and serious implications for building other > branches or for fixes for older product branches. This problem also exists > with the previous build system, for the same reasons, but was apparently > never attempted to be resolved by my predecessor. > > At this point, I'm toying with the idea of building up a separate Jenkins > implementation for every branch - its messy but will resolve the > hermaphroditic install problem for a while. However, its probably not > going to work for an active dev branch, where it would be normal to > withdraw api changes instead of always moving forward. > > I also thought about adding all the .h and .so files as deliverables, and > adding the required path to the LD_LIBRARY_PATH and INCLUDE_PATH, but aside > from these getting extremely long with 187 of them, some of them (device > drivers, etc.) extend and replace existing Debian base functionality, so > its another point where the installed product can be at variance with these > simplistic path inclusions. > > Has anybody got an idea for how to get this to a more scalable and robust > build environment? > > -- > 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/d/optout. > -- Thanks! Mark Waite -- 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/d/optout.
