Hi
a nice approach, but why this complicated ? 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? --> I mean when Lib is changed, why should you immediately want to compile App1 ? 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. 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. >
