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 20:22:18 GMT
Joshua,

I took a quick tour of the plugin... is it simply the check-box and defining
the location of the ivy file? The instructions on the Hudson page show the
"Build other projects" checked as well.

On Fri, Aug 7, 2009 at 1: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