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 18:16:33 GMT
Chris,

I haven't seen this plugin. Interesting concept... looks better than manual
triggers through Hudson and hacking building by monitoring VCS.

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.
> > > >
> > >
>

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