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 16:37:39 GMT
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