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 19:00:39 GMT
Yes. This is exactly what I was asking for is best practices. Tthis isn't
really an Ivy problem, but using Ivy definitely exposes the need for
thinking about the problem and managing it.

On Fri, Aug 7, 2009 at 10:41 AM, 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 is dependent
> > > on. To
> > > > me
> > > > > this looks very like bad practice, but I'm uncertain of the toolset
> > > > > available to me.
> > > > >
> > > > > Any feedback is appreciated.
> > > > >
> > > >
> >
>
> ----------------------------------------------------------------------
> 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