ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Tharp <joshua-th...@alumni.calpoly.edu>
Subject Re: Ivy feedback mechanisms for spawning builds...
Date Fri, 07 Aug 2009 20:10:53 GMT
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
View raw message