Thank you both, I think you win the point. I will discuss it with the other developpers and integrator. As soon as i have a configuration satisfying me, i will post it here for information.
With kind rewards, Benjamin Baumann 2010/7/16 Daniel Nauck <[email protected]> > Hi, > > i can confirm ruben's explanation. > It was till this day the best solution for a large real world project > with over 150 assemblies/projects. > > But you can also create a new CCNet project that gets the latest binary of > Lib A and tests compilation + unit tests agains the main project. > > Example: > - Project for Lib A > - Project for MainApp > - Project for integrationtest of latest Lib A + MainApp > > Daniel > > Am 16.07.2010 12:33, schrieb Ruben Willems: > > Hi > > that remains to be seen :-) > > suppose : The guys on the lib project are working very hard : 50 commits a > day > > Do you really want to see 50 broken builds for every main project ? > those 'broken' builds are not the fault of a 'main' project ! > > A programmer of a main project has it's own tasks, and as long as the > current version of his lib is ok, > why should he upgrade to every in-between version of lib (which has not > been tested, ...) > > > and how much time is it so update the reference? > copy over the new files > check in > > 5 minutes work at most > > > > with kind regards > Ruben Willems > > On Fri, Jul 16, 2010 at 12:17 PM, Benjamin Baumann <[email protected] > > wrote: > >> This effectively sounds more reasonable and cleaner. >> I will see if the amount of time lost whenever you update the lib with >> this method (update by hand each project depending on lib) is worth the >> change. >> >> What annoys me is that I not only don't automate the process, but i add >> more handmade work (test each project instead of letting CC.NET do the >> tests). >> >> >> 2010/7/16 Ruben Willems <[email protected]> >> >>> Hi >>> >>> >>> but you use the dlls from lib, are these dll's not in a separate folder >>> structure in your main project? >>> >>> root >>> refs >>> lib >>> src >>> main >>> >>> >>> so whenever lib changes, a 'main' project will not break, because it uses >>> it's own 'copy / version' of lib >>> >>> when you want to change to a new version of lib, replace the one in the >>> refs folder, and you can see if it works or not >>> before you check in. >>> >>> That sounds like a more reasonable approach >>> >>> >>> with kind regards >>> Ruben Willems >>> >>> >>> On Fri, Jul 16, 2010 at 10:28 AM, Benjamin Baumann < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> I want to do what you tell, I can do it with forcebuild publisher or >>>> with a project trigger. This is not problematic. >>>> >>>> But I also want to check if lib must be built when I want to build main. >>>> For example, if there is a commit for both projects main & lib : I want >>>> lib to be built before. As far as I understand the doc, queues can order >>>> project builds but only pending projects. >>>> >>>> If there is no project building when the commit is done. Main will maybe >>>> trigger before lib and then my queue will be like this : >>>> >>>> 1. main (svn trigger) >>>> 2. lib (svn trigger) >>>> 3. main (forcebuild or project trigger) >>>> >>>> The first problem is that main is built two times, the second is that >>>> the first build of main may be broken because it would use the old lib. >>>> >>>> >>>> With kind regards, >>>> Benjamin Baumann >>>> >>>> 2010/7/16 Ruben Willems <[email protected]> >>>> >>>> Hi >>>>> >>>>> >>>>> so you use the dll's from the lib assembly in your 'main' project. >>>>> --> this is ok >>>>> >>>>> and when the lib is changed, you want to recompile all apps that use >>>>> this lib correct? >>>>> >>>>> >>>>> >>>>> with kind regards >>>>> Ruben Willems >>>>> >>>>> On Fri, Jul 16, 2010 at 10:11 AM, Benjamin Baumann < >>>>> [email protected]> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Unfortunately my lib project (in fact I have many projects matching >>>>>> this case) is used by several main project. >>>>>> If I have a solution for each main project, I need each time to >>>>>> specify the path to the libs projects and these paths may change >>>>>> according >>>>>> to the computer where the development takes place. >>>>>> >>>>>> That's why I prefer to reference dll built in the integration server, >>>>>> and that's why I have to re-build (if needed) these dlls prior to build >>>>>> the >>>>>> main project. >>>>>> >>>>>> With kind regards, >>>>>> Benjamin Baumann >>>>>> >>>>>> 2010/7/15 Ruben Willems <[email protected]> >>>>>> >>>>>> Hi >>>>>>> >>>>>>> why not have 1 solution that has lib and main? >>>>>>> >>>>>>> so the solution takes care of the dependencies. >>>>>>> >>>>>>> >>>>>>> with kind regards >>>>>>> Ruben Willems >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 15, 2010 at 5:12 PM, Benjamin Baumann < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I read the doc and lots of articles and I ended up with the idea >>>>>>>> that there is no easy way to build dependancies before the triggered >>>>>>>> project >>>>>>>> itself. I just would like to know if I am right or if I forget >>>>>>>> something? >>>>>>>> >>>>>>>> ForceBuild is quite a solution but it cannot prevent duplicate >>>>>>>> builds if by example I commit changes for both project lib and main >>>>>>>> (where >>>>>>>> main depends on the output of lib), the build of the main project may >>>>>>>> be >>>>>>>> triggered before the build of the lib project and i would end with a >>>>>>>> queue >>>>>>>> like >>>>>>>> 1. main (svn trigger) >>>>>>>> 2. lib (svn trigger) >>>>>>>> 3. main (forcebuild) >>>>>>>> >>>>>>>> I actually want the build queue to be : >>>>>>>> 1. lib >>>>>>>> 2. main (forcebuild) >>>>>>>> >>>>>>>> But to achieve this, i need a way to force lib to be built before >>>>>>>> main... >>>>>>>> >>>>>>>> Thanks you in advance, >>>>>>>> Benjamin Baumann >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
