I use the Hudson Ivy plugin, and it does figure out both the upstream and downstream dependencies from the ivy.XML files. What it doesn't do (or at least I haven't figured it out yet) is not build a module when you have multiple dependencies that all lead to the same one. For example, if C depends on A and B and B also depends on A, then when A is updated Hudson will likely build C twice (once when A is complete and again when B is rebuilt.
On Friday, August 7, 2009, Shawn Castrianni <[email protected]> wrote: > I think what is being asked is how to enhance the CI system so that not only > does it detect changes to the SCM system (which would obviously require a > rebuild), but to also detect changes in that module's dependencies in the > repository since a change in a dependency should also require a rebuild. So > what methods or best practices have been developed to have a CI system check > if a module's dependencies have changed since last time it was built to cause > a rebuild? > > This might be more of a "pull" technique. The "push" technique might be more > of what was already stated in this thread of having an extra step at the end > of a build to automatically trigger any other module that has a dependency on > the module just built. > > --- > Shawn Castrianni > > -----Original Message----- > From: Mitch Gitman [mailto:[email protected]] > Sent: Friday, August 07, 2009 11:53 AM > To: [email protected] > Subject: Re: Ivy feedback mechanisms for spawning builds... > > OK, I understand what's going on now. One thing to keep in mind is the > distinction between upstream/dependency projects and downstream/dependent > projects. Obviously, an ivy.xml tells you only about its dependencies. My > understanding, though, (and I could be wrong about this) is that the Hudson > Ivy plugin is able to figure out the downstream path. I'd asked about as > much in this thread and got an affirmative: > http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html > > Frankly, I haven't found much value in having a plugin automatically figure > out which projects to build once one project has built. I've been fine to do > that manually. But I recognize some people may find value in that. > > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris > <[email protected]>wrote: > >> I can't tell if you've considered this already, but have you looked at the >> Ivy plugin for Hudson? >> >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin >> >> Apparently it looks at an ivy file in a project and handles building >> dependencies, though I haven't tried it. >> >> Chris >> >> > -----Original Message----- >> > From: Kevin Gann [mailto:[email protected]] >> > Sent: Friday, 07 August, 2009 11:38 >> > To: [email protected] >> > Subject: Re: Ivy feedback mechanisms for spawning builds... >> > >> > Maybe I mis-understood but... I've built the model that you illustrate. >> > :) >> > >> > version control system commit --> CI server build --> Ivy publish to >> > shared >> > repository >> > >> > The problem comes with other projects within VCS which I'd like rebuilt >> > because a new artifact has been published. With my current knowledge I >> > could >> > configure Hudson to use a "build trigger" and build after another build >> > takes place and utilize latest.integration (or similar) for the >> > revision. >> > >> > Like I said... it feels wrong to have Hudson hold that configuration, >> > but I >> > suppose if CI is only monitoring VCS how else would it know? A hack >> > would be >> > to have CI monitor the share which holds the artifacts I want to >> > rebuild >> > with. >> > >> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <[email protected]> wrote: >> > >> > > Kevin, it sounds like you're thinking about the problem in the wrong >> > way. >> > > Leaving aside the case of the Ivysvn resolver where Subversion is >> > doubling >> > > as an Ivy resolver, your CI server should really be the party >> > responsible >> > > for publishing to your shared Ivy repository. The thing that's >> > triggering >> > > the CI server is commits to the version control system. This is the >> > typical >> > > relationship because it works and makes sense. >> > > >> > > Illustrated like so: >> > > version control system commit --> CI server build --> Ivy publish to >> > shared >> > > repository >> > > >> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <[email protected]> wrote: >> > > >> > > > I'm trying to figure out how to tell my CI system in an elegant way >> > that >> > > an >> > > > artifact published to my Ivy repository has changed. Right now I >> > > > artificially give this feedback using Hudson which forces a build >> > to be >> > > > executed once a library is published which a project >> > > > ---------------------------------------------------------------------- > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message. >
