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 <[email protected]> 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 <[email protected]> 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. > > >
