Answers inline.. On Wed, Oct 14, 2009 at 7:50 PM, Ruben Willems <[email protected]> wrote: > Hi > > > a nice approach, but why this complicated ?
I'm retrofitting CI into what we already have. > you have project monitoring a repository, and when changes are detected > force build other projects. > why not let each project watch its own repository, or part from it? Currently, we only have one repository. Each project has a bunch of directories within the repository that it depends on. If each project watches its own repository, then no arrangement (that I could find) of priorities/queues would always result in projects building (or not building) in the correct order. Even for the simple example on my original post, there is no arrangement of project priorities that would ensure that everything that is supposed to get built does, and nothing that isn't supposed to get built does. Feel free to prove me wrong, though. > --> I mean when Lib is changed, why should you immediately want to compile > App1 ? Because it is too easy for a change in Lib to break one of the many things it depends on. Why would you not want to find out as soon as possible whether you have broken anything? > let app1 reference a binary release of Lib. > and from time to time, upgrade that library. > > you can even set up a nightky build that each day copies the latest 'build' > of lib, > in the referenced folder of App1, to check the latest version of lib breaks > compatibility. > This is what I do. > > So the people maintaining lib do not have to worry that a checkin breaks the > entire chain. > When they're done with the new features / bug fixes, they test it and > release the lib. > and our applications take that version, copy it into the path used by their > programs. The problem there is that, if I want to make a change to App1, that involves changes to the lib, I want to be able to just go and change the lib. I don't want unnecessary walls between the components. We don't have separate teams for each app (though we do have experts). Flexibility and productivity is important to us. So anyway, is there a way for a task to cancel pending items? I'm sure I can work something out, but I'd rather not do something too hacky if there is a clean way. Cheers, Carl. > > with kind regards > Ruben Willems > > > On Wed, Oct 14, 2009 at 6:26 AM, Carl Cerecke <[email protected]> > wrote: >> >> I want to temporarily disable a project from being queued if I know >> beforehand that queueing it will result in a broken build. >> >> I have a project hierarchy shaped like the attached png. An arrow >> indicates a forcebuild from forceBuildPublisher. The source for this >> graph is: >> >> digraph { >> Lib -> App1 >> Lib -> App2 >> App1 -> Doc >> App2 -> Doc >> Doc -> MSI >> Tut -> MSI >> } >> >> The actual project hierarchy is considerably more complicated, but >> this simple example is sufficient for the explanation. >> >> None of these projects have a source control component, rather, a >> custom source-watcher plugin watches the source for all projects, and >> then triggers the appropriate projects if the source changes. The >> source-watcher project has the lowest priority (runs last), and Lib >> (or possibly Tut) has the highest priority. This ensures that a full >> build will take place without interruptions before the source is >> checked for modifications again by the source-watcher plugin. >> >> The problem comes when a build fails. Assume the source-watcher has >> detected a change in the source for Lib and Tut. When Lib gets built, >> it triggers App1 and App2. If App1 fails, but App2 succeeds, App2 >> shouldn't forcebuild Doc. Conversely, if App1 succeeds (and >> forcebuilds Doc), but App2 fails, Doc should be removed from the >> queue. In either case, Tut should still build, but if it builds >> successfully, it shouldn't forcebuild MSI. >> >> My proposed solution is that, when a build fails, it should remove all >> descendants from the queue, and 'poison' those descendants so they >> can't be added to the queue. The source-watcher project, having the >> lowest priority, can then clear the 'poisonous' projects in a >> <prebuild>. >> >> I think I've got the 'posion' functionality sorted out: Failed >> projects publish all their descendants to a 'posion.txt' file, and a >> plugin to replace ForceBuildPublisher (just subclasses it and adds a >> property) that checks the posion.txt file before forcing a build. >> >> I'm not sure, though, how to remove all pending descendants from the >> same queue. I know what the descendants are, and I can see the >> CancelPendingRequest() method on IProjectIntegrator, but I'm just not >> sure how to get to it from a subclass of TaskBase (1.5.0 obviously). >> >> Any help appreciated, even (especially!) if you think my solution is >> completely wrong! >> >> Cheers, >> Carl. >> -- >> Carl Cerecke >> GeoBase Senior Software Engineer – Telogis Research >> www.telogis.com www.telogis.co.nz >> -- >> This e-mail, and any attachments, is intended only for use by the >> addressee(s) named herein and may contain legally privileged and/or >> confidential information. It is the property of Telogis. If you are >> not the intended recipient of this e-mail, you are hereby notified >> that any dissemination, distribution or copying of this e-mail, any >> attachments thereto, and use of the information contained, is strictly >> prohibited. If you have received this e-mail in error, please notify >> the sender and permanently delete the original and any copy there of. > > -- Carl Cerecke GeoBase Senior Software Engineer – Telogis Research www.telogis.com www.telogis.co.nz -- This e-mail, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Telogis. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, any attachments thereto, and use of the information contained, is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the original and any copy there of.
