I switched this company from CruiseControl to Hudson when I started and haven't looked back. I'll take a look at QB and Bamboo though for familiarity.
On Fri, Aug 7, 2009 at 3:28 PM, Shawn Castrianni < [email protected]> wrote: > I don't want this email thread to turn into a CI server comparison, but we > use QuickBuild2. I love it! However, it does not currently have any IVY > integration yet, but it does have support for plugins. If you haven't > looked at QuickBuild since they released the QB2 beta, you might want to > give it another chance. > > --- > Shawn Castrianni > > > -----Original Message----- > From: Gareth Western [mailto:[email protected]] > Sent: Friday, August 07, 2009 5:20 PM > To: [email protected] > Subject: Re: Ivy feedback mechanisms for spawning builds... > > We use Atlassian Bamboo for our CI server. Bamboo does have a rather basic > mechanism for specifying "child" and "parent" builds for each build plan, > however it has no knowledge of the ivy.xml configuration files, > unfortunately. Also, it does have a few shortcomings though, such as not > being able to work out an optimal build order [1]. > For now we don't use Bamboo for our release builds, but instead have a > separate Ant script which just builds each module in the correct order. > > [1] http://forums.atlassian.com/message.jspa?messageID=257281517 > > <http://forums.atlassian.com/message.jspa?messageID=257281517> > > On Fri, Aug 7, 2009 at 9:10 PM, Joshua Tharp < > [email protected]> wrote: > > > 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. > > > > > >
