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.
