ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Gann <kay...@gmail.com>
Subject Re: Ivy feedback mechanisms for spawning builds...
Date Fri, 07 Aug 2009 23:54:47 GMT
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 <
Shawn.Castrianni@halliburton.com> 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:gareth@garethwestern.com]
> Sent: Friday, August 07, 2009 5:20 PM
> To: ivy-user@ant.apache.org
> 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 <
> joshua-tharp@alumni.calpoly.edu> 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
> > <Shawn.Castrianni@halliburton.com> 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:mgitman@gmail.com]
> > > Sent: Friday, August 07, 2009 11:53 AM
> > > To: ivy-user@ant.apache.org
> > > 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 <
> Chris.Hilton@zilliant.com
> > >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:kaygee@gmail.com]
> > >> > Sent: Friday, 07 August, 2009 11:38
> > >> > To: ivy-user@ant.apache.org
> > >> > 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 <mgitman@gmail.com>
> > 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 <kaygee@gmail.com>
> > 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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message